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
signature.asc
Description: PGP signature
