> On Mon, Jun 19, 2023 at 09:30:12PM +1200, Thomas Munro wrote:
> On Mon, Jun 19, 2023 at 6:50 PM Thomas Munro <thomas.munro@gmail.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
Great, thanks! Can confirm, after applying both the posted patch and the
change above the issue is not reproducible anymore.
One thing I've noticed is that one can observe a similar issue using a
gin index and int[] for the "path" column, even applying changes from
the thread. The gin implementation does something similar to btree in
startScanEntry -- it lands in "No entry found" branch, but instead of
locking the relation it locks "the leaf page, to lock the place where
the entry would've been, had there been one". The similar fix retrying
ginFindLeafPage didn't solve the problem, even if locking the whole
relation instead, but maybe I'm missing something.