| 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: | Whole Thread | Raw Message | 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. |