Horton
Menu

Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data

Noah Misch <noah@leadboat.com>

View thread
From: Noah Misch <noah@leadboat.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@bowt.ie>
Date: 2021-08-15T08:45:35Z
Lists: pgsql-bugs 
On Sat, Aug 14, 2021 at 03:13:28PM -0700, Noah Misch wrote:
> On Sun, Aug 08, 2021 at 09:37:52AM -0700, Noah Misch wrote:
> > On Sun, Aug 08, 2021 at 04:31:07PM +0500, Andrey Borodin wrote:
> > > Step 1. Test for CIC with regular transactions.
> > > Step 2. Fix
> > > Step 3. Test for CIC with 2PC
> > > Step 4. Part of the fix that I'm sure about
> > > Step 5. Dubious part of fix...
> 
> When I applied all five to commit b33259e^ (shortly before the PostgresNode
> compatibility break) and ran your tests in a loop, I got more 2PC "lacks
> matching index tuple" within one minute.  Here's how I ran the tests:
> 
>   make -j20 && while make -C contrib/amcheck check REGRESS= PROVE_FLAGS=--timer PROVE_TESTS='t/002_cic.pl t/003_cic_2pc.pl' NO_TEMP_INSTALL=1; do date; done
> 
> Do you see failures with that loop?  If so, can you diagnose them?

See below.

> (So far, I've not seen a failure from the 1PC test.)

I eventually did see one.  Just one 1PC failure in six hours of 1PC test
runtime, though.

> On Thu, Jul 29, 2021 at 10:25:48PM -0400, Noah Misch wrote:
> > I haven't checked whether other inval message types have the same hazard.
> 
> I will look into this next.  (It probably doesn't explain 2PC failures.)

Now that I've looked, other inval hazards might indeed explain the remaining
2PC and 1PC failures.  I'll plug those holes and see what failures, if any,
continue to happen.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Improve contrib/amcheck's tests for CREATE INDEX CONCURRENTLY.

  2. Fix minor memory leaks in pg_dump.

  3. Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.

  4. Fix CREATE INDEX CONCURRENTLY for the newest prepared transactions.

  5. Add -w back to the flags for pg_ctl (re)start in PostgresNode

  6. Fix CREATE INDEX CONCURRENTLY for simultaneous prepared transactions.