Re: lost lock during toasting allows fk violation

On Mon, Jul 27, 2026 at 11:45:59PM -0700, Jacob Brazeal wrote:
> I ran a few trials of the same strategy but with no reindex step, relying
> instead on the time it takes to insert a very large TOAST value to hold the
> lock. Times here are taken from a sample script run:

The REINDEX makes that slightly easier. For example, I was able to
just use an isolation test that renames a TOAST table and trigger the
issue. No need for a concurrent workload.

> So, this can be reproduced in the wild without too much hand-holding.

Hmm. Couldn't one say that it is an ordering problem with the xmax
computation in heap_update()?

There is a window between the initial xmax computation and the TOAST
and/or page extension work where we could have concurrent updates, due
to the buffer lock getting released while we work on the TOAST data.
Concurrent transactions are then free to manipulation states, and the
xmax information gets overwritten in an incorrect way because it is
only written *before* touching TOAST. We could recompute it after the
TOAST/extension part is done, when the buffer lock is acquired again,
I guess? This way we would be able to keep track of the FK locks that
may have been added in-between.

While looking at moving these blocks, I am not completely sure yet
about the part with locker_remains and checked_lockers. I'd assume
that we should recheck the xmax information with a
xmax_infomask_changed() and a RawXmax(), or something like that..

Adding in CC. Peter G. and Alvaro for this one.
--
Michael