Re: Use XLOG_CONTROL_FILE macro everywhere?

> On 27 Apr 2024, at 11:12, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 26.04.24 22:51, Tom Lane wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> On Wed, Apr 24, 2024 at 8:04 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>>>> Not sure that I would bother with a second one. But, well, why not if
>>>> people want to rename it, as long as you keep compatibility.
>>> I vote for just standardizing on XLOG_CONTROL_FILE. That name seems
>>> sufficiently intuitive to me, and I'd rather have one identifier for
>>> this than two. It's simpler that way.
>> +1. Back when we did the great xlog-to-wal renaming, we explicitly
>> agreed that we wouldn't change internal symbols referring to xlog.
>> It might or might not be appropriate to revisit that decision,
>> but I sure don't want to do it piecemeal, one symbol at a time.
>> Also, if we did rename this one, the logical choice would be
>> WAL_CONTROL_FILE not PG_CONTROL_FILE.
>
> My reasoning was mainly that I don't see pg_control as controlling just the WAL. But I don't feel strongly about instigating a great renaming here or something.

Summarizing the thread it seems consensus is using XLOG_CONTROL_FILE
consistently as per the original patch.

A few comments on the patch though:

- * reads the data from $PGDATA/global/pg_control
+ * reads the data from $PGDATA/<control file>

I don't think this is an improvement, I'd leave that one as the filename
spelled out.

- "the \".old\" suffix from %s/global/pg_control.old.\n"
+ "the \".old\" suffix from %s/%s.old.\n"

Same with that change, not sure I think that makes reading the errormessage
code any easier.

--
Daniel Gustafsson