From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Offline data checksum changes can cause incorrect checksum state on standbys
Date: Mon, 31 Aug 2026 08:01:00 +0000
Message-ID: <apU0vKrffQDmmv68@bdtpg> (raw)
In-Reply-To: <8DCA12FF-0199-403D-A203-666528A25DB6@yesql.se>
References: <apEdrmkoNT6R9XyJ@bdtpg>
<6370C439-408D-40F6-B956-55DF19FFE41C@yesql.se>
<apFTwa68Qn0S0dIX@bdtpg>
<CAN4CZFOv4CZfj0i1oesNhZV68zMN7SQtZPLJFEQip2dG=Pf-8Q@mail.gmail.com>
<apGltAexjCkHPatS@bdtpg>
<CAN4CZFMaw79Yd-sV=g=016xX3kpijD0WH3fPJEAkSusZwn7Avw@mail.gmail.com>
<apJGv8fffeUfSkCL@bdtpg>
<CAN4CZFMoDj7mbY231r-pmPywwJpneksUiNXDwkNokkveGtobQg@mail.gmail.com>
<apUL3N4IE934qJ08@bdtpg>
<8DCA12FF-0199-403D-A203-666528A25DB6@yesql.se>
Hi,
On Mon, Aug 31, 2026 at 09:16:52AM +0200, Daniel Gustafsson wrote:
> > On 31 Aug 2026, at 07:06, Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote:
> >
> > Fixing this would probably require recording additional ordering information for
> > offline changes, adding even more complexity to v5. Another option would be to
> > document that the standby must be fully caught up before both nodes are stopped
> > for the offline operation.
>
> I think we really need to think about documenting a lot of this, potentially
> even to the point of saying that offline and online changes should not be mixed
Yeah, that could make sense, at least to make the limitation explicit and warn
users about these cases.
> as they work with completely different durability models.
Yeap.
> The more I think about this the less excited I am about contorting the logic of
> a feature which does proper WAL logging to cope with a tool that doesn't,
> including misuses like creating mismatched clusters. We should probably start
> to look at improving pg_checksums such that transitions are WAL logged rather
> than shoehorning in such changes with a WAL logged flow. pg_checksums rewrites
> the datadirectory without the postmaster given any information that any change
> was made, which in itself should be a red flag.
I agree.
> Making sure that StartupXLOG
> can detect the offline change (or something along those lines) and properly log
> it seems like a better starting point.
That sounds worth exploring. Would the idea be for pg_checksums to leave a
marker in pg_control which StartupXLOG would turn into a WAL logged transition?
> >>> Do you see the control version change as a concern?
> >>
> >> Yes, it is another non-trivial change in an already complex patch,
> >> really close to RC1. It's also not an area where we could easily
> >> implement bug fixes in a minor version, if we discover something
> >> later.
> >
> > Yeah, and I think the case above reinforces that concern.
>
> I don't think the above reinforces not wanting to do a pg_control change at
> this point. I think it reinforces that changing datafiles without WAL logging
> is a fairly slippery slope.
Yeah, I see your point that the underlying issue is the non WAL logged change.
My concern was not about a pg_control change in itself, but that addressing this
case might require further changes to the current pg_control design, which adds
risk this close to RC1.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: bertranddrouvot.pg@gmail.com, daniel@yesql.se, zsolt.parragi@percona.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Offline data checksum changes can cause incorrect checksum state on standbys
In-Reply-To: <apU0vKrffQDmmv68@bdtpg>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox