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

On Mon, Aug 31, 2026 at 11:46 AM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> This part
>
> > > And even without assertions, the new database on the standby silently
> > > loses all all-visible/all-frozen bits and all free space data of every
> > > copied relation.
>
> is true completely independently of my commit. Only the assert is new
> and would require changes to v19. I didn't think of this way of ending
> up with a discrepancy between primary and standby VM. I assumed that
> if the VM bit was not set on the primary it would not be set on the
> standby. Even if we commit something to eliminate this corner case
> (with RelationCopyStorageUsingBuffer()), you could probably end up
> with a lost or truncated VM on the primary and the VM being set on the
> standby in some other way, so we shouldn't assume that the
> visibilitymap_set() will dirty the buffer. We can't set the page LSN
> unless we marked the buffer dirty, so for 19, I think I could just do
> if (BufferIsDirty()) -> PageSetLSN()
> In master, it probably makes sense to change back the signature of
> visibilitymap_set() to report if it did actually set the bit(s) and
> then use that to decide whether to set the page LSN. Unless we don't
> think it is too late in 19 to change the visibilitymap_set() API. It
> does mean all the other callers of visibilitymap_set() are going to
> discard the return value, but maybe that's okay?

Since we are putting out a beta 4, I feel fine about changing the
visiblitymap_set() API back. Here is a patch that does that.

- Melanie