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-19T02:29:46Z
Lists: pgsql-bugs 
How is this schedule supposed to work?

S1:  _bt_search(&buf)
S1:  if (!BufferIsValid(buf)) // because index is empty
S1:  {
S1:    PredicateLockRelation(...);
S1:    ...
S1:    return false; // no tuples for you

S2:  _bt_search(&buf)

S1:  INSERT ...

S2:  if (!BufferIsValid(buf)) // because index *was* empty
S2:  {
S2:    PredicateLockRelation(...);
S2:    ...
S2:    return false; // no tuples for you

S2:  ...

My point is that S2 won't ever scan S1's tuples, so it won't pass S1's
xid to CheckForSerializableConflictOut().  Am I missing something?  I
can repro this with NR_THREADS set to only 2, after inserting
pg_usleep(1) after the _bt_search() in _bt_first() (sched_yield()
wasn't quite enough).

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.