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

On Tue, Jun 20, 2023 at 1:22 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Tue, Jun 20, 2023 at 12:18 AM Dmitry Dolgov <9erthalion6(at)gmail(dot)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?