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 09:30:12 |
Message-ID: | CA+hUKGJATT51T0Vkg0FDkQa5boQv-WoqL1_KM=313ySu0MVqig@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Jun 19, 2023 at 6:50 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> ... 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. ...
Ahh, here's such a place. I can't reproduce it with the patch already
posted + this check commented out.
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2127,16 +2127,18 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
hscan->rs_cindex = 0;
hscan->rs_ntuples = 0;
+#if 0
/*
* Ignore any claimed entries past what we think is the end of the
* relation. It may have been extended after the start of our scan (we
* only hold an AccessShareLock, and it could be inserts from this
* backend).
*/
if (block >= hscan->rs_nblocks)
return false;
+#endif
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2023-06-19 10:21:43 | Re: BUG #17978: Unexpected error: "wrong varnullingrels (b) (expected (b 5)) for Var 6/2" triggered by JOIN |
Previous Message | Thomas Munro | 2023-06-19 06:50:59 | Re: BUG #17949: Adding an index introduces serialisation anomalies. |