Re: Is the XLP_BKP_REMOVABLE flag itself removable/obsolete?

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: Is the XLP_BKP_REMOVABLE flag itself removable/obsolete?
Date: 2026-03-02 05:20:13
Message-ID: aaUeDZZt01hKtsE4@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 27, 2026 at 08:15:22AM +0900, Michael Paquier wrote:
> Let's just remove this flag. I would have let XLP_ALL_FLAGS as it is
> now at 0x000F, though. It is just used for filtering the bits we
> allow to exist in this area of the header, for validation. Perhaps
> some forks like this extensibility if they have their own extra custom
> bits, meaning less code to modify. That's a minor point for sure, but
> people like hacking on Postgres and forking this code.

Done. The patch missed a variable declaration not required anymore in
AdvanceXLInsertBuffer(), that I have caught with a compiler warning.
Another thing that did not feel right was to mark 0x0004 as free, so I
have moved the contrecord value one level down and updated
XLP_ALL_FLAGS accordingly, like ff9f111bce24 and 2dd9322ba6ee.
XLOG_PAGE_MAGIC also got its bump.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-03-02 05:47:16 Re: pg_basebackup: removed an unnecessary use of memset in FindStreamingStart
Previous Message Corey Huinker 2026-03-02 05:18:36 Re: Add starelid, attnum to pg_stats and leverage this in pg_dump