> On Aug 11, 2026, at 02:07, Daniel Gustafsson <[email protected]> wrote:
>
>> On 10 Aug 2026, at 16:21, Ian Lawrence Barwick <[email protected]> wrote:
>> 2026年8月10日(月) 22:30 Fujii Masao <[email protected]>:
>
>>> On Mon, Aug 10, 2026 at 9:39 PM Ian Lawrence Barwick <[email protected]>
>>> 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/
