On Wed, Sep 16, 2026 at 10:26 AM Melanie Plageman <[email protected]> wrote: > > I now think we have to do something. While exploring another adjacent > topic, I realized that tuple locking has a seemingly unsolvable > problem with this. > > If you have a page set all-frozen in the VM and then do CREATE > DATABASE STRATEGY WAL_LOG, your new database will have that page set > all-frozen in the VM on the primary and set neither all-visible nor > all-frozen on the standby. When that standby is promoted, you now have > a primary with the page NOT set all-frozen and a standby with the page > set all-frozen. If you then lock the tuple on the primary, it will > emit a WAL record with no XLH_LOCK_ALL_FROZEN_CLEARED flag because the > primary did not need to clear all-frozen. The standby will update the > xmax but not clear the all-frozen bit in the VM. Now you have a heap > page with a live xmax that is set all-frozen in the VM. > > Basically, if you have some all-frozen data and do CREATE DATABASE > STRATEGY WAL_LOG and then failover and then do a SELECT FOR UPDATE, > you'll have data corruption. That seems bad.
I attached an LLM-generated reproducer. - Melanie
repro-noop-vm-frozen-lock-portable.sh
Description: application/shellscript
