renaming "transaction log"

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 of

The 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