Re: WAL_LOG CREATE DATABASE strategy broken for non-standard page layouts

On Wed, Sep 16, 2026 at 10:26 AM Melanie Plageman
<melanieplageman(at)gmail(dot)com> 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