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