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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal
Дата
Msg-id 20170126231904.3qyzghacn7piuxmu@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On 2017-01-26 15:45:15 -0700, David G. Johnston wrote:
> On Thu, Jan 26, 2017 at 3:28 PM, Andres Freund <andres@anarazel.de> wrote:
>
> > I *personally* don't think it's worth
> > changing all this without taking more care about backward compat than
> > we're apparently willing to do.  I'm ok with loosing that argument.  I
> > just don't think the previous concensus for a narrower change can be
> > used for the wider one
> > ​.
> >
>
> ​It would probably help others if you could brain dump a bit as to the
> benefit of the status-quo compared to both the 9.6 behavior and the all-in
> one.

Well, I think I've lost that argument, so I'm not sure how much effort
we should spent on litigating my opinion on it.  But here we go:

As I said somewhere upthread (when discussing the function names), I
think we're playing it too fast and loose with unnecessary changes.

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.


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 actually took your response as: "why the f**k is he talking about
> camels?" and started laughing...

That's good then, and let's raise a $beverage_of_choice tonight to the
fallability of e-mail conversation ;)


Andres



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jia Yu
Дата:
Сообщение: Re: [HACKERS] IndexBuild Function call fcinfo cannot access memory
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: [HACKERS] BUG: pg_stat_statements query normalization issues withcombined queries