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, Teodor Sigaev <teodor@sigaev.ru>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2023-06-20T22:54:15Z
Lists: pgsql-bugs 
On Tue, Jun 20, 2023 at 1:22 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Tue, Jun 20, 2023 at 12:18 AM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
> > One thing I've noticed is that one can observe a similar issue using a
> > gin index and int[] for the "path" column, even applying changes from
> > the thread. The gin implementation does something similar to btree in
> > startScanEntry -- it lands in "No entry found" branch, but instead of
> > locking the relation it locks "the leaf page, to lock the place where
> > the entry would've been, had there been one". The similar fix retrying
> > ginFindLeafPage didn't solve the problem, even if locking the whole
> > relation instead, but maybe I'm missing something.
>
> Ouch.  I would have to go and study gin's interlocking model, but one
> superficial bug I spotted is that ginget.c's collectMatchBitmap()
> calls PredicateLockPage(stack->buffer), where a block number is
> expected.  I wish we had strong typedefs, to reject stuff like that at
> compile time.  But fixing that alone isn't enough.
>
> In case someone who knows more about gin is interested in helping, I
> attach Artem's repro, modified to use gin.

This is probably going to go faster if I CC the authors of commit
0bef1c06.  Any ideas about how we're missing rw-conflicts under high
concurrency?

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.