Re: pg_control_checkpoint(): add "data_checksum_version" (Pg19)?

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Ian Lawrence Barwick <barwick(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_control_checkpoint(): add "data_checksum_version" (Pg19)?
Date: 2026-08-11 14:38:13
Message-ID: CAHGQGwHihdaqfY-GoBzPyNAa0fJaQjH+C7ZcqT2mbRA4rL_0dA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 11, 2026 at 3:07 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> I originally opted against displaying the mapped name to keep
> pg_control_checkpoint a way to extract the raw data, but thinking about it
> might be more useful to show the mapped value since the mapping is private.

I suggested making pg_controldata report the latest checkpoint's checksum state
as text rather than as a version. But, I found that pg_controldata reports
similar information "Data page checksum version", and pg_control_init()
exposes data_page_checksum_version as an integer version.

This makes me wonder whether we should drop my suggestion and keep the latest
checkpoint's checksum field as a version as well, or instead move toward
reporting textual checksum states consistently in all these places.
Or is there another approach that would make more sense?

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2026-08-11 14:41:22 Re: Support EXCEPT for TABLES IN SCHEMA publications
Previous Message Andrey Rachitskiy 2026-08-11 14:31:26 Fix PGTYPESdate_fmt_asc overflow when a year does not fit "yyyy"