On Fri, Feb 3, 2017 at 8:50 AM, Daniel Verite <dan...@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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to