Re: Changing the state of data checksums in a running cluster - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Changing the state of data checksums in a running cluster
Date
Msg-id EC4ED8A7-A9C5-4D92-B528-1303E97EEB48@yesql.se
Whole thread Raw
In response to Re: Changing the state of data checksums in a running cluster  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Changing the state of data checksums in a running cluster
List pgsql-hackers
> On 18 Mar 2026, at 09:06, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> On 18/03/2026 00:01, Daniel Gustafsson wrote:

>>> What if a database is dropped and another one is created with the same database OID?
>> Good point.  We have the name of the database so we could compare Oid and name,
>> and require both to match.  That would still be foiled by a new database using
>> the same Oid and name though.  Any ideas on what could be done?
> Well, if CREATE DATABASE computed the checksums, that would fix this too. Actually, at least in the default
wal_log=truemode, doesn't it already do that? It goes through the buffer cache as usual, I presume the checksums will
becomputed too. 

That's a very good point, if the CREATE DATABASE is issued with wal_log and not
file_copy it will mark the buffers dirty during copying which will calculate
and set the checkpoint.  If file_copy isn't allowed during inprogress-on then
the logic around rescanning databases for new entries could be quite
simplified.

--
Daniel Gustafsson




pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Fix slotsync worker busy loop causing repeated log messages
Next
From: "Greg Burd"
Date:
Subject: Re: another autovacuum scheduling thread