renaming "transaction log"
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t36623psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 06:52 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t36623_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t36623_1 && git checkout t36623_1Patchset v1 (message #1) is on t36623_1
Most documentation and error messages still uses the term "transaction
log" to refer to the write-ahead log. Here is a patch to rename that,
which I think should be done, to match the xlog -> wal renaming in APIs.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter,
* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
Most documentation and error messages still uses the term "transaction
log" to refer to the write-ahead log. Here is a patch to rename that,
which I think should be done, to match the xlog -> wal renaming in APIs.
Haven't looked at the patch, but +1 for this change.
Thanks!
Stephen
On 5/2/17 9:09 PM, Peter Eisentraut wrote:
Most documentation and error messages still uses the term "transaction
log" to refer to the write-ahead log. Here is a patch to rename that,
which I think should be done, to match the xlog -> wal renaming in APIs.
+1 for the idea.
The documentation changes look good to me, but the error message changes
are a random mix of "WAL" and "write-ahead log", even when referring to
the same thing. For example:
- errmsg("could not open transaction log directory \"%s\": %m",
+ errmsg("could not open write-ahead log directory \"%s\": %m",and:
- fprintf(stderr, _("%s: failed to remove transaction log directory\n"),
+ fprintf(stderr, _("%s: failed to remove WAL directory\n"),It seems like they should be one or the other. I think "write-ahead
log" is good in the documentation since it is more explanatory, but the
error messages should either be all "write-ahead log" or all "WAL".
Personally I favor "WAL" for brevity in the error messages, but I would
be OK with "write-ahead log", too.
--
-David
david@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut wrote:
Most documentation and error messages still uses the term "transaction
log" to refer to the write-ahead log. Here is a patch to rename that,
which I think should be done, to match the xlog -> wal renaming in APIs.
+1 for the idea. I suggest grepping for "transaction$" too -- there are
a few cases in SGML that have the phrase "transaction log" split across
lines.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 03, 2017 at 10:57:06AM -0300, Alvaro Herrera wrote:
Peter Eisentraut wrote:
Most documentation and error messages still uses the term "transaction
log" to refer to the write-ahead log. Here is a patch to rename that,
which I think should be done, to match the xlog -> wal renaming in APIs.+1 for the idea. I suggest grepping for "transaction$" too -- there are
a few cases in SGML that have the phrase "transaction log" split across
lines.
In general, you can use ag a.k.a. "The Silver Searcher" for phrase
searches as follows:
ag $(echo "the phrase to be searched" | sed -e 's/ /\\s/g')
Thanks to Dagfinn Ilmari Manns�ker for the tip :)
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 03, 2017 at 10:33:32AM -0700, David Fetter wrote:
On Wed, May 03, 2017 at 10:57:06AM -0300, Alvaro Herrera wrote:
Peter Eisentraut wrote:
Most documentation and error messages still uses the term "transaction
log" to refer to the write-ahead log. Here is a patch to rename that,
which I think should be done, to match the xlog -> wal renaming in APIs.+1 for the idea. I suggest grepping for "transaction$" too -- there are
a few cases in SGML that have the phrase "transaction log" split across
lines.In general, you can use ag a.k.a. "The Silver Searcher" for phrase
searches as follows:ag $(echo "the phrase to be searched" | sed -e 's/ /\\s/g')
Oops. That should read:
ag $(echo "the phrase to be searched" | sed -e 's/ /\\s+/g')
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David Fetter wrote:
On Wed, May 03, 2017 at 10:33:32AM -0700, David Fetter wrote:
On Wed, May 03, 2017 at 10:57:06AM -0300, Alvaro Herrera wrote:
Peter Eisentraut wrote:
Most documentation and error messages still uses the term "transaction
log" to refer to the write-ahead log. Here is a patch to rename that,
which I think should be done, to match the xlog -> wal renaming in APIs.+1 for the idea. I suggest grepping for "transaction$" too -- there are
a few cases in SGML that have the phrase "transaction log" split across
lines.In general, you can use ag a.k.a. "The Silver Searcher" for phrase
searches as follows:
ag $(echo "the phrase to be searched" | sed -e 's/ /\\s+/g')
Nice, thanks. So after applying Peter's patch, this grep returns the
following (after removing the *.po files from the result):
src/backend/access/transam/transam.c:4: * postgres transaction log interface routines
Probably change to "commit log"; this one is not related to WAL.
doc/src/sgml/release-old.sgml:631:<listitem><para>Fix race condition in transaction log management</para>
doc/src/sgml/release-old.sgml:2245:<listitem><para>Prevent possible compressed transaction log loss (Tom)</para></listitem>
doc/src/sgml/release-old.sgml:2282:<listitem><para>Fix for compressed transaction log id wraparound (Tom)</para></listitem>
doc/src/sgml/release-8.2.sgml:5163: Allow a forced switch to a new transaction log file (Simon, Tom)
doc/src/sgml/release-8.2.sgml:5168: in sync with the master. Transaction log file switching now also happens
doc/src/sgml/release-8.2.sgml:5172: transaction log files needed for recovery can be archived immediately.
doc/src/sgml/release-8.2.sgml:5182: Add functions for interrogating the current transaction log insertion
doc/src/sgml/release-8.2.sgml:5222: to force transaction log file switches at a given interval (Simon)
doc/src/sgml/release-8.0.sgml:2582:<listitem><para>Fix race condition in transaction log management</para>
doc/src/sgml/release-9.6.sgml:3180: to expose the current transaction log flush location (Tomas Vondra)
doc/src/sgml/release-7.4.sgml:1950:<listitem><para>Fix race condition in transaction log management</para>
Leave old release notes untouched.
doc/src/sgml/release-10.sgml:2362: 2016-11-09 [41124a91e] pgbench: Allow the transaction log file prefix to be cha
doc/src/sgml/release-10.sgml:2520: 2016-10-23 [56c7d8d45] Allow pg_basebackup to stream transaction log in tar mod
Comments, ignore. (First one is unrelated anyway.)
doc/src/sgml/high-availability.sgml:141: <term>Transaction Log Shipping</term>
doc/src/sgml/high-availability.sgml:292: <entry>Transaction Log Shipping</entry>
I think it'd make sense to flip these two to Write-Ahead Log Shipping
too. (Why aren't there index entries for the term? Maybe add two
entries, one for "transaction log" and another one for WAL).
doc/src/sgml/wal.sgml:241: <primary>transaction log</primary>
Leave this one alone, add another indexentry for the WAL terminology.
doc/src/sgml/ref/pg_receivewal.sgml:35: from a running <productname>PostgreSQL</productname> cluster. The transaction
doc/src/sgml/ref/pg_receivewal.sgml:36: log is streamed using the streaming replication protocol, and is written
Peter missed this one.
doc/src/sgml/ref/pg_receivewal.sgml:43: <application>pg_receivewal</application> streams the transaction
doc/src/sgml/ref/pg_receivewal.sgml:44: log in real time as it's being generated on the server, and does not wait
Ditto.
doc/src/sgml/ref/pg_basebackup.sgml:181: the cluster has no additional tablespaces and transaction
doc/src/sgml/ref/pg_basebackup.sgml:182: log streaming is not used.
Ditto.
doc/src/sgml/ref/pgbench.sgml:1126: <title>Per-Transaction Logging</title>
Unrelated, don't change.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
Most documentation and error messages still uses the term "transaction
log" to refer to the write-ahead log. Here is a patch to rename that,
which I think should be done, to match the xlog -> wal renaming in APIs.
This will need to be rebased over d10c626de, which made a few of the
same/similar changes but did not try to hit stuff that wasn't adjacent
to what it was changing anyway. I'm +1 for the idea though. I think
we should also try to standardize on the terminology "WAL location"
for LSNs, not variants such as "WAL position" or "log position".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Committed, adjusting for some of the suggestions.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 5/3/17 09:10, David Steele wrote:
The documentation changes look good to me, but the error message changes
are a random mix of "WAL" and "write-ahead log", even when referring to
the same thing.
The reason for this is that some of the error messages refer to a
--waldir option or something like it, so it seems appropriate to also
refer to "WAL" in the error messages.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
Committed, adjusting for some of the suggestions.
Looks like one occurrence was still left in:
$ ag --no-group --ignore po --ignore release-\* --ignore wal.sgml '\btransaction\s+log\b'
doc/src/sgml/func.sgml:18631: end of the transaction log at any instant, while the write location is the end of
The four other occurrences in the same paragraph were fixed, so I assume
this was just an oversight.
- ilmari
--
"I use RMS as a guide in the same way that a boat captain would use
a lighthouse. It's good to know where it is, but you generally
don't want to find yourself in the same spot." - Tollef Fog Heen
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 5/11/17 12:00, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
Most documentation and error messages still uses the term "transaction
log" to refer to the write-ahead log. Here is a patch to rename that,
which I think should be done, to match the xlog -> wal renaming in APIs.This will need to be rebased over d10c626de, which made a few of the
same/similar changes but did not try to hit stuff that wasn't adjacent
to what it was changing anyway. I'm +1 for the idea though. I think
we should also try to standardize on the terminology "WAL location"
for LSNs, not variants such as "WAL position" or "log position".
done
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 5/12/17 12:12, Dagfinn Ilmari Manns�ker wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
Committed, adjusting for some of the suggestions.
Looks like one occurrence was still left in:
$ ag --no-group --ignore po --ignore release-\* --ignore wal.sgml '\btransaction\s+log\b'
doc/src/sgml/func.sgml:18631: end of the transaction log at any instant, while the write location is the end ofThe four other occurrences in the same paragraph were fixed, so I assume
this was just an oversight.
Fixed, thanks.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers