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: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, artem.anisimov.255@gmail.com, pgsql-bugs@lists.postgresql.org, Teodor Sigaev <teodor@sigaev.ru>
Date: 2023-06-28T03:18:00Z
Lists: pgsql-bugs

Attachments

On Mon, Jun 26, 2023 at 8:04 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> Yes, +1 on the patches. Any chance of constructing test cases for these?

Thanks for looking.  I can't think of any good way to test
deterministically.  All three depend on unlucky scheduling.  Perhaps
if we had one of those 'pause insertion' systems that I have heard
talk of.

> >               /*
> > -              * We only get here if the index is completely empty. Lock relation
> > -              * because nothing finer to lock exists.
> > +              * Since we have no pages locked, it's possible for another
> > +              * transaction to insert data between _bt_search() and
> > +              * PredicateLockRelation().  We have to try again after taking a
> > +              * relation-level predicate lock, to close a narrow window where we
> > +              * wouldn't scan concurrently inserted tuples, but the writer wouldn't
> > +              * see our predicate lock.
> >                */
>
> I'd like to keep the old comment here, it's good context, and add the
> new text in addition to the old.

Done.

> v3-0002-Fix-race-in-SSI-interaction-with-bitmap-heap-scan.patch: Can we
> keep the optimization when not using SSI?

Done.

I'll push these in a couple of days if there are no further comments.

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.