Horton

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

Dmitry Dolgov <9erthalion6@gmail.com>

View thread View on postgr.es
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Thomas Munro <thomas.munro@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-23T14:05:42Z
Lists: pgsql-bugs 
> On Thu, Jun 22, 2023 at 10:02:19PM +1200, Thomas Munro wrote:
> On Wed, Jun 21, 2023 at 9:04 PM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
> > Now the reading transaction actually does PredicateLockPage on the
> > metabuffer inside scanPendingInsert, but strangely enough it doesn't
> > lock anything because the SerializationNeededForRead condition is false.
> > I'm trying to verify if it's somehow a part of the issue, or something
> > is broken on my side.
>
> Maybe you were confused by the presence of non-SSI transactions in the
> repro (eg the transaction that sets up the index)?

Yeah, sort of. Need to optimize the way how I consume the logs.

> To answer my own earlier question, the conflict-in check for posting
> trees is hidden in getFindLeafPage(..., true, ...).
>
> I spent some more time trying to grok this today.  FTR it reproduces
> faster without the extra tuple that repro I posted inserts after
> TRUNCATE (the point of that was to find out whether it was an
> empty-to-non-empty transition).  I still don't know what's wrong but I
> am beginning to suspect the "fast" code.  It seems as though, under
> high concurrency, we sometimes don't scan a recently inserted
> (invisible to our snapshot, but needed for SSI checks) tuple, but I
> don't yet know why.

Yep, it's definitely something in the "fast" path. Testing the same, but
with an index having (fastupdate=off) works just fine for me.

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.