Thread: pgsql: Use the terminology "WAL file" not "log file" more consistently.
Use the terminology "WAL file" not "log file" more consistently. Referring to the WAL as just "log" invites confusion with the postmaster log, so avoid doing that in docs and error messages. Also shorten "WAL segment file" to just "WAL file" in various places. Bharath Rupireddy, reviewed by Nathan Bossart and Kyotaro Horiguchi Discussion: https://postgr.es/m/CALj2ACUeXa8tDPaiTLexBDMZ7hgvaN+RTb957-cn5qwv9zf-MQ@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/31dcfae83c001c6cdfd1e67c11adb9149f564da0 Modified Files -------------- doc/src/sgml/backup.sgml | 14 +++---- doc/src/sgml/config.sgml | 4 +- doc/src/sgml/protocol.sgml | 2 +- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- doc/src/sgml/ref/pg_waldump.sgml | 10 ++--- doc/src/sgml/wal.sgml | 60 +++++++++++++-------------- src/backend/access/transam/xlogreader.c | 10 ++--- src/backend/access/transam/xlogrecovery.c | 6 +-- src/backend/access/transam/xlogutils.c | 4 +- src/backend/replication/walreceiver.c | 6 +-- src/backend/utils/misc/postgresql.conf.sample | 8 ++-- src/bin/pg_resetwal/pg_resetwal.c | 2 +- src/bin/pg_upgrade/controldata.c | 2 +- src/bin/pg_waldump/pg_waldump.c | 4 +- 14 files changed, 67 insertions(+), 67 deletions(-)
Re: pgsql: Use the terminology "WAL file" not "log file" more consistently.
From
Andrew Dunstan
Date:
On 2022-09-14 We 18:41, Tom Lane wrote: > Use the terminology "WAL file" not "log file" more consistently. > > Referring to the WAL as just "log" invites confusion with the > postmaster log, so avoid doing that in docs and error messages. > Also shorten "WAL segment file" to just "WAL file" in various > places. The pg_upgrade part of this seems seriously awry (see buildfarm animal crake). We can't assume that the upgrade source is using the new wording. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
> The pg_upgrade part of this seems seriously awry (see buildfarm animal
> crake). We can't assume that the upgrade source is using the new wording.
Ugh. I'll look into a fix tomorrow --- but my first instinct is
that pg_upgrade shouldn't be so dependent on the exact wording of
pg_controldata output.
regards, tom lane
Re: pgsql: Use the terminology "WAL file" not "log file" more consistently.
From
Bharath Rupireddy
Date:
On Thu, Sep 15, 2022 at 7:08 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Andrew Dunstan <andrew@dunslane.net> writes: > > The pg_upgrade part of this seems seriously awry (see buildfarm animal > > crake). We can't assume that the upgrade source is using the new wording. > > Ugh. I'll look into a fix tomorrow --- but my first instinct is > that pg_upgrade shouldn't be so dependent on the exact wording of > pg_controldata output. Yeah, buildfarm member crake complains [1] about the change [2]. pg_upgrade basically expects that the controldata output be consistent across source and target servers, the way it does is by invoking pg_resetwal with -n option. Backporting [2] down to all the supported PG versions doesn't work, because the pg_upgrade can fail while upgrading from non-supported PG version without [2] to supported PG version with [2]. We seem to be maintaining old code in pg_upgrade to not break it, see [3]. I can think of a fix [4] or just [5], it may not be great to do these kinds of fixes for all the pg_resetwal output changes. Since the changes we make to the output formats of controlfile or pg_resetwal are very rare, any of [4] or [5] looks good to me and it is better than backporting [2] IMO. Thoughts? [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2022-09-14%2023%3A17%3A32 [2] index d4772a2965..7adf79eeed 100644 --- a/src/bin/pg_resetwal/pg_resetwal.c +++ b/src/bin/pg_resetwal/pg_resetwal.c @@ -788,7 +788,7 @@ PrintNewControlValues(void) XLogFileName(fname, ControlFile.checkPointCopy.ThisTimeLineID, newXlogSegNo, WalSegSz); - printf(_("First log segment after reset: %s\n"), fname); + printf(_("First WAL segment after reset: %s\n"), fname); [3] else if ((p = strstr(bufin, "First log file ID after reset:")) != NULL) else if ((p = strstr(bufin, "First log file segment after reset:")) != NULL) [4] diff --git a/src/bin/pg_upgrade/controldata.c b/src/bin/pg_upgrade/controldata.c index 88d7e1c73d..c35eb84c20 100644 --- a/src/bin/pg_upgrade/controldata.c +++ b/src/bin/pg_upgrade/controldata.c @@ -348,7 +348,10 @@ get_control_data(ClusterInfo *cluster, bool live_check) cluster->controldata.chkpnt_nxtmxoff = str2uint(p); got_mxoff = true; } - else if ((p = strstr(bufin, "First WAL segment after reset:")) != NULL) + else if ((GET_MAJOR_VERSION(cluster->major_version) < 1600 && + (p = strstr(bufin, "First log segment after reset:")) != NULL) || + (GET_MAJOR_VERSION(cluster->major_version) >= 1600 && + (p = strstr(bufin, "First WAL segment after reset:")) != NULL)) { /* Skip the colon and any whitespace after it */ p = strchr(p, ':'); [5] diff --git a/src/bin/pg_upgrade/controldata.c b/src/bin/pg_upgrade/controldata.c index 88d7e1c73d..5386139b12 100644 --- a/src/bin/pg_upgrade/controldata.c +++ b/src/bin/pg_upgrade/controldata.c @@ -348,7 +348,8 @@ get_control_data(ClusterInfo *cluster, bool live_check) cluster->controldata.chkpnt_nxtmxoff = str2uint(p); got_mxoff = true; } - else if ((p = strstr(bufin, "First WAL segment after reset:")) != NULL) + else if ((p = strstr(bufin, "First WAL segment after reset:")) != NULL || + (p = strstr(bufin, "First log segment after reset:")) != NULL) { /* Skip the colon and any whitespace after it */ p = strchr(p, ':'); -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> writes:
> We seem to be maintaining old code in pg_upgrade to not break it, see
> [3]. I can think of a fix [4] or just [5], it may not be great to do
> these kinds of fixes for all the pg_resetwal output changes. Since the
> changes we make to the output formats of controlfile or pg_resetwal
> are very rare, any of [4] or [5] looks good to me and it is better
> than backporting [2] IMO.
Yeah, the lowest-tech solution is to accept either spelling of
the description string. But I'm not very happy with the whole
approach right now. We should have an implementation that isn't
dependent on how user-friendly strings are spelled. (git seems
a bit ahead of us here, with its distinction between "plumbing"
and "porcelain" operations.)
regards, tom lane
Re: pgsql: Use the terminology "WAL file" not "log file" more consistently.
From
Alvaro Herrera
Date:
On 2022-Sep-15, Tom Lane wrote: > Yeah, the lowest-tech solution is to accept either spelling of > the description string. But I'm not very happy with the whole > approach right now. We should have an implementation that isn't > dependent on how user-friendly strings are spelled. We already discussed this, a mere 12 years ago, https://postgr.es/m/1283373680-sup-9235@alvh.no-ip.org for exactly the same reason. Let's just do it? -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ Y una voz del caos me habló y me dijo "Sonríe y sé feliz, podría ser peor". Y sonreí. Y fui feliz. Y fue peor.
On 9/15/22 05:24, Alvaro Herrera wrote: > On 2022-Sep-15, Tom Lane wrote: > >> Yeah, the lowest-tech solution is to accept either spelling of >> the description string. But I'm not very happy with the whole >> approach right now. We should have an implementation that isn't >> dependent on how user-friendly strings are spelled. > > We already discussed this, a mere 12 years ago, > https://postgr.es/m/1283373680-sup-9235@alvh.no-ip.org > for exactly the same reason. Nice! > Let's just do it? +1 -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Re: pgsql: Use the terminology "WAL file" not "log file" more consistently.
From
Bharath Rupireddy
Date:
On Thu, Sep 15, 2022 at 2:54 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > On 2022-Sep-15, Tom Lane wrote: > > > Yeah, the lowest-tech solution is to accept either spelling of > > the description string. But I'm not very happy with the whole > > approach right now. We should have an implementation that isn't > > dependent on how user-friendly strings are spelled. > > We already discussed this, a mere 12 years ago, > https://postgr.es/m/1283373680-sup-9235@alvh.no-ip.org > for exactly the same reason. > > Let's just do it? Thanks for pointing it out. It seems like a good idea IMO. I think pg_resetwal also needs the --machine approach. As --machine approach needs a good amount of refactoring and discussion, I still think we can make buildfarm happy by fixing a proposed solution [1]. Perhaps, we can start a new thread for --machine approach. Thoughts? [1] https://www.postgresql.org/message-id/CALj2ACVKH2v5s_qFDd9YxPhmRKL%2BOC4ukUdWaD3t1MWV5W7ZLA%40mail.gmail.com -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> writes:
> Thanks for pointing it out. It seems like a good idea IMO. I think
> pg_resetwal also needs the --machine approach. As --machine approach
> needs a good amount of refactoring and discussion, I still think we
> can make buildfarm happy by fixing a proposed solution [1]. Perhaps,
> we can start a new thread for --machine approach.
Agreed; here on -committers is certainly no place for that.
For the moment I'm just going to revert the change in pg_controldata
output, because it occurred to me that pg_upgrade might not be the
only tool side-swiped by that. We can put it back after we have
some more-stable output format that such tools can start using.
regards, tom lane