> On 27 Apr 2024, at 11:12, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 26.04.24 22:51, Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Wed, Apr 24, 2024 at 8:04 PM Michael Paquier <michael@paquier.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
instigatinga 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
