Re: Bug with pg_basebackup and 'shared' tablespace

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.
>

+1

It seems simply wrong (and potentially dangerous) to allow users to
arrange a system state that cannot be backed up (easily/without surgery
etc etc).

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.

regards

Mark