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)?
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.