Rename RECOVERYXLOG to RECOVERYWAL?
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:t37345psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 10:24 PM.
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 t37345_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 t37345_1 && git checkout t37345_1Patchset v1 (message #1) is on t37345_1
I searched the various threads on the xlog -> wal rename and I couldn't
find any specific mention of why this was not renamed.
I have attached a patch in case it was an oversight rather than left
as-is on purpose.
Thanks,
--
-David
david@pgmasters.net
On Fri, Sep 1, 2017 at 12:57 PM, David Steele <david@pgmasters.net> wrote:
I searched the various threads on the xlog -> wal rename and I couldn't
find any specific mention of why this was not renamed.I have attached a patch in case it was an oversight rather than left
as-is on purpose.
I don't think this really buys us anything. If we'd applied it to v10
maybe, but what do we get out of whacking it around now?
"Consistency", I hear you cry! Fair point. But we never had a goal
of eliminating all internal references to "xlog", just the user-facing
ones. And since RECOVERYXLOG is not documented, I think there's a
good argument that it's not user-facing. You could argue that since
it shows up in the file system it's implicitly user-facing, and maybe
you're right; if some other committer really wants to make this
change, I won't grouse much. But personally I'd favor leaving it
alone to avoid having the behavior change a little bit in every new
release.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9/1/17 2:06 PM, Robert Haas wrote:
On Fri, Sep 1, 2017 at 12:57 PM, David Steele <david@pgmasters.net> wrote:
I searched the various threads on the xlog -> wal rename and I couldn't
find any specific mention of why this was not renamed.I have attached a patch in case it was an oversight rather than left
as-is on purpose.I don't think this really buys us anything. If we'd applied it to v10
maybe, but what do we get out of whacking it around now?
I was thinking it would be applied to v10.
"Consistency", I hear you cry! Fair point. But we never had a goal
of eliminating all internal references to "xlog", just the user-facing
ones. And since RECOVERYXLOG is not documented, I think there's a
good argument that it's not user-facing. You could argue that since
it shows up in the file system it's implicitly user-facing, and maybe
you're right;
That's exactly my argument, in fact!
if some other committer really wants to make this
change, I won't grouse much. But personally I'd favor leaving it
alone to avoid having the behavior change a little bit in every new
release.
Seems like since v10 is still beta and this is not really documented it
wouldn't be that big a deal to make the change. If nothing else it
might keep the question from coming up in the future.
I'm not going to make a big fuss about it, though. I noticed it while
testing the v10 support in pgbackRest and thought it was worth bringing up.
Thanks,
--
-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
On Sat, Sep 2, 2017 at 3:06 AM, Robert Haas <robertmhaas@gmail.com> wrote:
I don't think this really buys us anything. If we'd applied it to v10
maybe, but what do we get out of whacking it around now?"Consistency", I hear you cry! Fair point. But we never had a goal
of eliminating all internal references to "xlog", just the user-facing
ones. And since RECOVERYXLOG is not documented, I think there's a
good argument that it's not user-facing. You could argue that since
it shows up in the file system it's implicitly user-facing, and maybe
you're right; if some other committer really wants to make this
change, I won't grouse much. But personally I'd favor leaving it
alone to avoid having the behavior change a little bit in every new
release.
I may be wrong, but I would suspect that some backup tools doing
FS-level backup are checking on the existence of this file and skip
it. From the point of view of operations, it does not matter much as
any existing RECOVERYXLOG is unlinked before being replaced by a new
one, but that would not be nice to add silently 16MB in each backup.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9/1/17 7:53 PM, Michael Paquier wrote:
On Sat, Sep 2, 2017 at 3:06 AM, Robert Haas <robertmhaas@gmail.com> wrote:
I don't think this really buys us anything. If we'd applied it to v10
maybe, but what do we get out of whacking it around now?"Consistency", I hear you cry! Fair point. But we never had a goal
of eliminating all internal references to "xlog", just the user-facing
ones. And since RECOVERYXLOG is not documented, I think there's a
good argument that it's not user-facing. You could argue that since
it shows up in the file system it's implicitly user-facing, and maybe
you're right; if some other committer really wants to make this
change, I won't grouse much. But personally I'd favor leaving it
alone to avoid having the behavior change a little bit in every new
release.I may be wrong, but I would suspect that some backup tools doing
FS-level backup are checking on the existence of this file and skip
it. From the point of view of operations, it does not matter much as
any existing RECOVERYXLOG is unlinked before being replaced by a new
one, but that would not be nice to add silently 16MB in each backup.
Yes, pgBackRest does have an "offline" mode that can be used (when the
database is shutdown) to do an FS-level backup.
It never occurred to me to exclude RECOVERYXLOG but with 1GB WAL
segments coming in v11 it might be a good idea.
--
-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