Re: Bug with pg_basebackup and 'shared' tablespace

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: 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
Date: 2017-09-29 17:43:22
Message-ID: CA+TgmoYqOQOn_jwgC9V+w+5HfGH7Te5_FnCk3qvA4HzZ0UG0Pw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2017-09-29 17:43:48 Re: pgbench - minor fix for meta command only scripts
Previous Message Robert Haas 2017-09-29 17:31:16 Re: Refactor handling of database attributes between pg_dump and pg_dumpall