Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal
Дата
Msg-id CAKFQuwZ_nkTetT-hmJ6uBUmfT0GbNhgPCLQrB9aB3t3MdRMrzA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal  (Michael Paquier <michael.paquier@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Speedup twophase transactions
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal