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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Rogers Wang <rogers(dot)ww(at)qq(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: WAL_LOG CREATE DATABASE strategy broken for non-standard page layouts
Date: 2026-11-06 15:13:30
Message-ID: CA+TgmobaoRn6AEEv19Ri1BbMyUS0aOMNdcAOzShDn2JW8sq21w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 12, 2026 at 4:07 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> Upon further off-list discussion, instead of checking the AM, we can
> just check if the space between pd_upper and pd_lower is all zeroes.
> If it is, there is no harm in omitting it. It should always work,
> allows the optimization in more cases, and requires less code.
> Attached patch does that.

The problem with this approach is that it also includes the hole data
when the page is standard but the space between pd_upper and pd_lower
contains leftover garbage rather than zero bytes. That case is common:
when we prune-and-defragment heap pages, we don't zero the hole. I
think it would be worth trying to pass down the AM OID and always use
page_std = true for main-fork heap and btree pages (and maybe other
in-core AMs with no known legacy problems). That would mitigate the
practical downsides of the patch considerably. Whether you do that or
not, it's probably worth mentioning the performance concern in the
commit message. With that change, the downside would only exist for
out-of-core AMs, which do exist, and they could consider vigorous
hole-zeroing as a workaround.

--
Robert Haas
Databricks

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rafael Chacón 2026-11-06 16:00:45 Table synchronization cannot resume after a subscriber crash
Previous Message Andrew Dunstan 2026-11-06 15:13:14 Re: run pgindent in CI