From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
Cc: | artem(dot)anisimov(dot)255(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17949: Adding an index introduces serialisation anomalies. |
Date: | 2023-06-19 06:50:59 |
Message-ID: | CA+hUKG+3B7uBkJd4rr2FXhTc+95F3RvRovbhBM2UDt68aL5a-g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The attached shows one approach to the problem I described already,
namely scans of empty btrees that concurrently gain an initial root
page. This seems to fix the posted repro case if using a btree with
enable_seqscan=off, enable_bitmapscan=off. That's the variant I had
been working with, because it was simpler.
But that turns out to be only one problem hit by the repro.
Apparently there's a second bug, if you let it use bitmap heapscans.
Or perhaps I am misdiagnosing the above. It could be something like:
btgetbitmap not following the predicate lock protocol correctly (but
it looks OK at a glance), or bitmap heapscan not checking for
conflicts out comprehensively (xids on invisible tuples we scan), eg
not fetching heap tuples for some short cut reason somewhere. But
that's all I have time for today.
Attachment | Content-Type | Size |
---|---|---|
0001-Fix-rare-race-in-SSI-interaction-with-empty-btrees.patch | application/octet-stream | 2.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2023-06-19 09:30:12 | Re: BUG #17949: Adding an index introduces serialisation anomalies. |
Previous Message | Thomas Munro | 2023-06-19 03:23:31 | Re: BUG #17949: Adding an index introduces serialisation anomalies. |