Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Thu, Jan 26, 2017 at 4:19 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:

>
> We decided s/pg_xlog/pg_wal/ was necessary because people lost their
> data, and we couldn't come up with a reasonable way to change it without
> the name. The tradeoff is dataloss vs. dealing with directory renaming
> in a few lowlevel tools. So we decided to change the name. It seems
> breakage was unavoidable.
>
> For me the renaming of functions, binaries, etc, is different because
> the benefit is long-term avoidance of a bit of confusion, with the
> shorter term price being tool breakages and confusion because
> documentation/guides/... for different versions don't apply anymore, and
> the search terms don't help anymore. But we're still changing this,
> even though breakage seems avoidable.
>

Well stated and compelling.
​

>
> And that fits into the bigger topic of us doing minor cleanups without a
> lot of concern for backward compatibility, e.g. like us whacking things
> around in pg_stat_activity for most of the last releases - nearly all of
> those could have been done in a compatible manner, without even smelling
> that badly.
>
> I hear these complaints about postgres most frequently: 1) replication
> sucks. 2) way too slow on analytics queries. 3) existing admin tools
> suck. 4) self written admin tools (required due to 3)) constantly break.
>
> There's a lot being done on 1) and 2). There's very little in-core
> progress about 3). We're getting worse on 4).
>

​I would posit, broadly, and without any evidence, that changes like we are
discussing here, will go toward helping on 3 since (hopefully) as
PostgreSQL becomes a more appealing option in the marketplace more quality
developers will be drawn toward using their skills to improve its
ecosystem. Mandating uniformity in areas like this speaks toward
professionalism.

Given that "there's a lot being done on #1" it would seem that right now is
an excellent time to make these changes - so that the new guides and tools
that leverage those enhancements can use the WAL terminology and have its
presence be consistently present throughout the system.

If there was a reasonably short horizon for features or capabilities that
make this kind of renaming breaking easier to accommodate I would say we
could probably wait for it to be completed first. But AFAIK there isn't
anything in the works that would allow individual users to easily enable a
backward-compatibility mode for the mid-level API that we are largely
touching here.

It may be that this is a straw that breaks the camel's back for some users
of PostgreSQL who are fed up with #4 ... I don't know ... but I'm
reasonably confident that new users a couple of years from now would have a
better experience with our product with these changes in place. Its an
aggressive play for growth - and that entails risk and upsetting those
invested in the status-quo (which are are already doing per your #1).

David J.