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

From David G. Johnston
Subject Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal
Date
Msg-id CAKFQuwZ_nkTetT-hmJ6uBUmfT0GbNhgPCLQrB9aB3t3MdRMrzA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Thu, Jan 26, 2017 at 4:19 PM, Andres Freund <andres@anarazel.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.

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Speedup twophase transactions
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal