| 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
| 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 |