|From:||Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>|
|Cc:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pierre(dot)ducroquet(at)people-doc(dot)com, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Magnus Hagander <magnus(at)hagander(dot)net>|
|Subject:||Re: Bug with pg_basebackup and 'shared' tablespace|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 30/09/17 06:43, Robert Haas wrote:
> On Fri, Sep 29, 2017 at 2:06 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> My tendency about this patch is still that it should be rejected. This
>> is presenting additional handling for no real gain.
> I vehemently disagree. If the server lets you create a tablespace,
> then everything that happens after that ought to work.
> On another thread, there is the issue that if you create a tablespace
> inside $PGDATA, things break. We should either unbreak those things
> or not allow creating the tablespace in the first place. On this
> thread, there is the issue that if you create two tablespaces for
> different PG versions in the same directory, things break. We should
> either unbreak those things or not allow creating the tablespace in
> the first place.
> It is completely awful behavior to let users do things and then punish
> them later for having done them. Users are not obliged to read the
> minds of the developers and guess what things the developers consider
> "reasonable". They should be able to count on the principle that if
> they do something that we consider wrong, they'll get an error when
> they try to do it -- not have it superficially appear to work and then
> explode later.
> To put that another way, there should be ONE rule about what is or is
> not allowable in a particular situation, and all commands, utilities,
> etc. that deal with that situation should handle it in a uniform
> fashion. Each .c file shouldn't get to make up its own notion of what
> is or is not supported.
It seems simply wrong (and potentially dangerous) to allow users to
arrange a system state that cannot be backed up (easily/without surgery
Also the customer concerned that did exactly that started the
conversation about it with me like this (paraphrasing) 'So this
pg_basebackup thing is a bit temperamental...'. I'm thinking we do not
want to be giving users this impression.
|Next Message||Heikki Linnakangas||2017-10-01 06:38:34||Re: pgbench - minor fix for meta command only scripts|
|Previous Message||Pavel Stehule||2017-10-01 05:04:13||Re: extension build issue with PostgreSQL 10 on Centos6|