database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-10 17:42:29 +03:00
Code Activity

Rename "pg_xlog" directory to "pg_wal".

Browse Source 
"xlog" is not a particularly clear abbreviation for "write-ahead log",
and it sometimes confuses users into believe that the contents of the
"pg_xlog" directory are not critical data, leading to unpleasant
consequences.  So, rename the directory to "pg_wal".

This patch modifies pg_upgrade and pg_basebackup to understand both
the old and new directory layouts; the former is necessary given the
purpose of the tool, while the latter merely avoids an unnecessary
backward-compatibility break.

We may wish to consider renaming other programs, switches, and
functions which still use the old "xlog" naming to also refer to
"wal".  However, that's still under discussion, so let's do just this
much for now.

Discussion: CAB7nPqTeC-8+zux8_-4ZD46V7YPwooeFxgndfsq5Rg8ibLVm1A@mail.gmail.com

Michael Paquier
This commit is contained in:
Robert Haas
2016-10-20 11:24:37 -04:00
parent ec7db2b483
commit f82ec32ac3
37 changed files with 276 additions and 223 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
src/backend/replication/README
View File

@@ -54,7 +54,7 @@ and WalRcvData->slotname, and initializes the starting point in
WalRcvData->receiveStart.
As walreceiver receives WAL from the master server, and writes and flushes
it to disk (in pg_xlog), it updates WalRcvData->receivedUpto and signals
it to disk (in pg_wal), it updates WalRcvData->receivedUpto and signals
the startup process to know how far WAL replay can advance.
Walreceiver sends information about replication progress to the master server

20
src/backend/replication/basebackup.c
View File

@@ -346,7 +346,7 @@ perform_base_backup(basebackup_options *opt, DIR *tblspcdir)
TimeLineID tli;
/*
* I'd rather not worry about timelines here, so scan pg_xlog and
* I'd rather not worry about timelines here, so scan pg_wal and
* include all WAL files in the range between 'startptr' and 'endptr',
* regardless of the timeline the file is stamped with. If there are
* some spurious WAL files belonging to timelines that don't belong in
@@ -359,11 +359,11 @@ perform_base_backup(basebackup_options *opt, DIR *tblspcdir)
XLByteToPrevSeg(endptr, endsegno);
XLogFileName(lastoff, ThisTimeLineID, endsegno);
dir = AllocateDir("pg_xlog");
dir = AllocateDir("pg_wal");
if (!dir)
ereport(ERROR,
(errmsg("could not open directory \"%s\": %m", "pg_xlog")));
while ((de = ReadDir(dir, "pg_xlog")) != NULL)
(errmsg("could not open directory \"%s\": %m", "pg_wal")));
while ((de = ReadDir(dir, "pg_wal")) != NULL)
{
/* Does it look like a WAL segment, and is it in the range? */
if (IsXLogFileName(de->d_name) &&
@@ -401,7 +401,7 @@ perform_base_backup(basebackup_options *opt, DIR *tblspcdir)
qsort(walFiles, nWalFiles, sizeof(char *), compareWalFileNames);
/*
* There must be at least one xlog file in the pg_xlog directory,
* There must be at least one xlog file in the pg_wal directory,
* since we are doing backup-including-xlog.
*/
if (nWalFiles < 1)
@@ -1054,23 +1054,23 @@ sendDir(char *path, int basepathlen, bool sizeonly, List *tablespaces,
}
/*
* We can skip pg_xlog, the WAL segments need to be fetched from the
* We can skip pg_wal, the WAL segments need to be fetched from the
* WAL archive anyway. But include it as an empty directory anyway, so
* we get permissions right.
*/
if (strcmp(pathbuf, "./pg_xlog") == 0)
if (strcmp(pathbuf, "./pg_wal") == 0)
{
/* If pg_xlog is a symlink, write it as a directory anyway */
/* If pg_wal is a symlink, write it as a directory anyway */
size += _tarWriteDir(pathbuf, basepathlen, &statbuf, sizeonly);
/*
* Also send archive_status directory (by hackishly reusing
* statbuf from above ...).
*/
size += _tarWriteHeader("./pg_xlog/archive_status", NULL, &statbuf,
size += _tarWriteHeader("./pg_wal/archive_status", NULL, &statbuf,
sizeonly);
continue; /* don't recurse into pg_xlog */
continue; /* don't recurse into pg_wal */
}
/* Allow symbolic links in pg_tblspc only */

6
src/backend/replication/walreceiver.c
View File

@@ -18,7 +18,7 @@
* If the primary server ends streaming, but doesn't disconnect, walreceiver
* goes into "waiting" mode, and waits for the startup process to give new
* instructions. The startup process will treat that the same as
* disconnection, and will rescan the archive/pg_xlog directory. But when the
* disconnection, and will rescan the archive/pg_wal directory. But when the
* startup process wants to try streaming replication again, it will just
* nudge the existing walreceiver process that's waiting, instead of launching
* a new one.
@@ -365,7 +365,7 @@ WalReceiverMain(void)
* we've already reached the end of the old timeline, the server will
* finish the streaming immediately, and we will go back to await
* orders from the startup process. If recovery_target_timeline is
* 'latest', the startup process will scan pg_xlog and find the new
* 'latest', the startup process will scan pg_wal and find the new
* history file, bump recovery target timeline, and ask us to restart
* on the new timeline.
*/
@@ -742,7 +742,7 @@ WalRcvFetchTimeLineHistoryFiles(TimeLineID first, TimeLineID last)
tli)));
/*
* Write the file to pg_xlog.
* Write the file to pg_wal.
*/
writeTimeLineHistoryFile(tli, content, len);

4
src/backend/replication/walsender.c
View File

@@ -586,7 +586,7 @@ StartReplication(StartReplicationCmd *cmd)
* segment that contains switchpoint, but on the new timeline, so
* that it doesn't end up with a partial segment. If you ask for a
* too old starting point, you'll get an error later when we fail
* to find the requested WAL segment in pg_xlog.
* to find the requested WAL segment in pg_wal.
*
* XXX: we could be more strict here and only allow a startpoint
* that's older than the switchpoint, if it's still in the same
@@ -2058,7 +2058,7 @@ retry:
*
* For example, imagine that this server is currently on timeline
* 5, and we're streaming timeline 4. The switch from timeline 4
* to 5 happened at 0/13002088. In pg_xlog, we have these files:
* to 5 happened at 0/13002088. In pg_wal, we have these files:
*
* ...
* 000000040000000000000012