Re: Changing the state of data checksums in a running cluster

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: 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: 2024-10-11 07:57:13
Message-ID: 18750566-7D92-4FFE-9AAE-909AF99D3C33@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 9 Oct 2024, at 12:41, Tomas Vondra <tomas(at)vondra(dot)me> wrote:

>>> should use PG_DATA_CHECKSUM_INPROGRESS_ON_VERSION instead of the magic
>>> constant? For "off" we use "0" which seems somewhat acceptable, but for
>>> other values it's less obvious what the meaning is.
>>
>> It doesn't seem clean to include storage/bufpage.h in pg_upgrade, I wonder if
>> we should move (or mirror) the checksum versions to storage/checksum_impl.h to
>> make them available to frontend and backend tools?
>
> +1 to have checksum_impl.h

I tried various different ways of breaking out the checksum version into
another header file but all of them ended up messier than the current state due
to how various tools include the checksum code. In the end I opted for doing
the bufpage include to keep it simple. This patch is big enough as it is
without additional refactoring of checksum (header) code, that can be done
separately from this.

> I ran the tests with this new patch, and I haven't reproduced the
> crashes. I'll let it run a bit longer, and improve it to test some more
> stuff, but it looks good.

Thanks for testing, I am too unable to reproduce that error.

The attached v5 has the above include fix as well as pgindent and pgperltidy
runs and some tweaking to the commit message to make it concise. It's also
rebased to handle a recent conflict in the makefiles.

--
Daniel Gustafsson

Attachment Content-Type Size
v5-0001-Online-enabling-and-disabling-of-data-checksums.patch application/octet-stream 135.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2024-10-11 08:00:47 Re: CREATE INDEX regression in 17 RC1 or expected behavior?
Previous Message Yugo Nagata 2024-10-11 07:53:42 Re: CREATE INDEX regression in 17 RC1 or expected behavior?