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: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, 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-19 08:32:47
Message-ID: CAHGQGwGs3Zck_OBxeku2Z7vtmL2Hk3rOTZ5wbERRtMaa91pHog@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 19, 2026 at 5:04 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> I don't disagree with this, but I also don't think between beta3 and rc1 is a
> good time to remove fields (which have been there for a very long time) from
> system info functions. Revisiting this during v20 and cleaning it up seems
> like a very good idea though.

Yeah, I understand your point. On the other hand, I'm still not convinced
that adding data_checksum_version_init is a good idea either. Another
option would be to drop data_checksum_version_init and revert the change
to pg_control_init().data_page_checksum_version, so that it continues
to report the current data_checksum_version, as it does in v18.

This behavior does conflict with the docs for pg_control_init(), as you
pointed out: "pg_control_init is documented to return the state at cluster
initialization". But, this inconsistency already existed in v18. So that
seems acceptable for most users. It might also be less surprising
because the meaning of the value would remain unchanged between v18
and v19.

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2026-08-19 08:38:39 Re: pg_control_checkpoint(): add "data_checksum_version" (Pg19)?
Previous Message Daniel Gustafsson 2026-08-19 08:31:50 Re: [PATCH] Several refactorings for pg_dump