On 30/09/17 06:43, Robert Haas wrote:
On Fri, Sep 29, 2017 at 2:06 AM, Michael Paquier
<michael.paqu...@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
