Hi,
On 2022-05-31 12:09:04 -0700, Peter Geoghegan wrote:
> On Tue, May 31, 2022 at 11:54 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > On 2022-May-31, Peter Geoghegan wrote:
> > > This includes a patch from me, to make pruning more robust. It could
> > > technically be a bug in my patch, though a bug revealed by my patch
> > > seems quite possible too.
> >
> > Ah, I see. Well, the explanation that depends on Xmin doesn't apply to
> > this case. I'm not saying there are no bugs in the other two commits,
> > just that such bug(s) have a different explanation, so it makes sense to
> > revert separately.
>
> The assertion failure takes place in heapam_index_build_range_scan(),
> at the point that it is called by amcheck itself -- during an
> opportunistic prune that occurs in passing. This is the specific
> assertion that fails:
>
>
https://github.com/x4m/postgres_g/blob/09d76bdc2528b476ef2f04c793061dcbf23372b5/src/backend/access/heap/pruneheap.c#L762
I don't think that assertion is correct.
Consider transactions aborting concurrently with heap pruning. You could have
done a HTSV for one chain element, a concurrent abort happened, then you did
the HTSV for another chain element. If the HTSVs were not in the order of the
HOT chain you could see HEAPTUPLE_DEAD for an earlier chain element, while
seeing HEAPTUPLE_INSERT_IN_PROGRESS in a later one. There's several other
scenarios with subtransaction aborts as well, I think.
Greetings,
Andres Freund