Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal
Date
Msg-id CAB7nPqT=CGFpDmfGWQ-VUsDLaGjdC_T3hF8jtW4qmVZHdESDnA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-hackers
On Fri, Feb 3, 2017 at 8:50 AM, Daniel Verite <daniel@manitou-mail.org> wrote:
> What if we look at the change from the pessimistic angle?
> An example of confusion that the change would create:
> a lot of users currently choose pg_wal for the destination
> directory of their archive command.

Really? I find that surprising to say "a lot". Perhaps there are some,
but first I would not suspect that there are many people to use this
repository name, and even less crazy enough to store them directly in
PGDATA itself. And of course that's not on a different partition :)

> Also googling for pg_wal, I'm finding food for thought like this
> IBM technote:
> http://www-01.ibm.com/support/docview.wss?uid=isg3T1015637
> which recommends to
> "Remove all files under /var/lib/pgsql/9.0/data/pg_wal/"
> and also calls that directory the "write-ahead log directory"
> which is quite confusing because apparently it's the destination of
> their archive command.

Well this product of IBM is one.

> There's also the disruption in existing backup scripts that directly
> reference pg_xlog. Obviously these scripts are critical, and there's
> something weird in breaking that intentionally. The motivation of the
> breakage is likely to be felt as frivolous and unfair to those people who
> are adversely impacted by the change, even if the part of not
> reading the release notes is their fault.

Those are not complicated to fix because they are hard failures.
Sufficient tests need to be done so as backup scripts don't show in
red on live systems before deploying them. The original reason to do
the rename is that there are folks as well thinking that removing
pg_xlog is fine on full disk because, you know, it contains just
*logs* so they are not critical for the system.
-- 
Michael



pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal
Next
From: Craig Ringer
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions