Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal

Daniel,

* Daniel Verite (daniel(at)manitou-mail(dot)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. Less-informed users
> that set up archiving and/or log shipping in PG10 based on
> advice online from previous versions will be fairly
> confused about the missing pg_xlog, and the fact that the
> pg_wal directory they're supposed to create already exists.

One would hope that they would realize that's not going to work
when they set up PG10. If they aren't paying attention sufficient
to realize that then it seems entirely likely that they would feel
equally safe removing the contents of a directory named 'pg_xlog'.

> 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.

It's certainly unfortunate that people have thought that they can create
arbitrary directories under the PG data directory. That's never going
to be safe, witness that we've created new directories under PGDATA in
the last few releases and I don't see any reason why that would change
moving forward. Perhaps we should check for the existance of such a
directory during pg_upgrade and throw an error, and we should go back
and do the same for other directories which have been added over
releases, but I'm not sure I can see an argument for doing much more
than that.

> This brings the question: what about the people who will delete
> their pg_wal (ex-pg_xlog) when they face a disk-full condition and
> they mix up in their mind the archive directory and the WAL directory?

In my experience, at least, that's less likely to happen than someone
nuke'ing pg_xlog.

> It's hard to guess how many could make that mistake but I don't see
> why it would be less probable than confusing pg_xlog and pg_log.

Based on my experience, at least, that seems quite a bit less likely to
happen.

> At least the contents of the latter directories look totally
> different, contrary to the wal directory versus wal archive.

Sadly, that doesn't seem to have always made much of a difference.

> Also, what about the users who are helped currently by
> the fact that "pg_xlog" is associated at the top of google results
> to good articles that explain what it is, why it fills up and what
> to do about it? By burying the name "pg_xlog" we're also loosing that
> connection, and in the worst case making worse the problem we
> wanted to help with.

We'll have new articles about pg_wal which will be picked up by Google
also. I'm not quite sure how we would be making the problem worse
though- previously when it filled, a group of users believed it to be a
log directory which could be wiped out. With the new name, it's at
least clearer that it's not simple a directory of not-necessary log
files.

> 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.

While these scripts are critical, they're also likely to not be safe,
which is the unfortunate reality. If they're well written then they'll
break cleanly, quickly, and be easily fixed.

We will break things across major version upgrades. That's part of
the reason that we have major version upgrades, and why we support
released versions for years with bug fixes.

Thanks!

Stephen