| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, Andres Freund <andres(at)anarazel(dot)de>, Bernd Helmle <mailings(at)oopsware(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Michael Banck <mbanck(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Changing the state of data checksums in a running cluster |
| Date: | 2026-03-19 13:49:21 |
| Message-ID: | EC4ED8A7-A9C5-4D92-B528-1303E97EEB48@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 18 Mar 2026, at 09:06, Heikki Linnakangas <hlinnaka(at)iki(dot)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=true mode, doesn't it already do that? It goes through the buffer cache as usual, I presume the checksums will be computed 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Burd | 2026-03-19 13:49:34 | Re: another autovacuum scheduling thread |
| Previous Message | Fujii Masao | 2026-03-19 13:38:33 | Re: Fix slotsync worker busy loop causing repeated log messages |