Re: crash during cascaded foreign key update

On Wed, Mar 17, 2021 at 11:01 AM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Tue, Mar 16, 2021 at 11:17 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> > > With HEAD (I think v12 and greater), I see $subject when trying out
> > > the following scenario:

Actually, the crash is reproducible in all supported versions (9.6~),
although the failing Assert is different in branches older than 12.
The underlying issue is nevertheless the same.

> > I wonder if this is related to
> >
> > https://www.postgresql.org/message-id/flat/89429.1584443208%40antos
> >
> > which we've still not done anything about.
>
> Ah, indeed the same issue. Will read through that discussion first, thanks.

So, it appears that there's no live bug that actually manifests in the
real world use cases, even though the failing Assert shows that the
crosscheck snapshot handling code has grown inconsistent with its
surrounding code since it was first added in commit 55d85f42a89,
which, if I read correctly, also seems to the main conclusion of the
linked thread. I found the 2nd email in that thread very helpful to
understand the problem.

As for a solution, how about making heap_update() and heap_delete()
themselves report the error immediately upon a tuple failing the
crosscheck snapshot visibility test, instead of leaving it to the
caller which would definitely report the error in this case AFAICS?
If we do that, we don't really have to bother with figuring out sane
result codes for the crosscheck snapshot failure case. It also sounds
like that would be the easiest solution to back-patch.

I've attached a patch for that, which also adds isolation tests for these cases.

--
Amit Langote
EDB: http://www.enterprisedb.com