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

> On Aug 11, 2026, at 02:07, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
>> On 10 Aug 2026, at 16:21, Ian Lawrence Barwick <barwick(at)gmail(dot)com> wrote:
>> 2026年8月10日(月) 22:30 Fujii Masao <masao(dot)fujii(at)gmail(dot)com>:
>
>>> On Mon, Aug 10, 2026 at 9:39 PM Ian Lawrence Barwick <barwick(at)gmail(dot)com> wrote:
>>>> The function "get_checksum_state_string()" which performs the conversion is in
>>>> src/backend/access/rmgrdesc/xlogdesc.c, which AFAIR can't be linked from
>>>> frontend utilities, so we'd either have to move that somewhere else (maybe
>>>> src/common/controldata_utils.c?) or duplicate it.
>
> 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.
>
>>> Agreed. I think moving it to common is better than duplicating the mapping.
>>>
>>> src/common/controldata_utils.c seems like a reasonable place, since
>>> this state is stored in the control/checkpoint data and both pg_controldata
>>> and pg_control_checkpoint() already use controldata_utils.
>>
>> TBH it feels a little odd there because it's not really specific to
>> the controldata output functions, but it has to go somewhere, I guess.
>
> Yeah, I'm not convinced it's the right place but that being said I also don't
> have a better idea yet. If I can't think of a better place by the time the
> tree is open I say we go with this placement.
>

I don’t see a better place either.

Overall, v3 looks good to me. I only have one small comment. Since get_checksum_state_string() has been moved to a common location and can be called by both frontend and backend code, would it be better to give it a more specific name, such as get_data_checksum_state_string()?

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/