Horton

Re: BUG #17949: Adding an index introduces serialisation anomalies.

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: artem.anisimov.255@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-06-19T06:50:59Z
Lists: pgsql-bugs

Attachments

The attached shows one approach to the problem I described already,
namely scans of empty btrees that concurrently gain an initial root
page.  This seems to fix the posted repro case if using a btree with
enable_seqscan=off, enable_bitmapscan=off.  That's the variant I had
been working with, because it was simpler.

But that turns out to be only one problem hit by the repro.
Apparently there's a second bug, if you let it use bitmap heapscans.
Or perhaps I am misdiagnosing the above.  It could be something like:
btgetbitmap not following the predicate lock protocol correctly (but
it looks OK at a glance), or bitmap heapscan not checking for
conflicts out comprehensively (xids on invisible tuples we scan), eg
not fetching heap tuples for some short cut reason somewhere.  But
that's all I have time for today.

Commits

  1. Fix race in SSI interaction with bitmap heap scan.

  2. Fix race in SSI interaction with gin fast path.

  3. Fix race in SSI interaction with empty btrees.

  4. Re-think predicate locking on GIN indexes.