Re: pgsql: Fix pg_basebackup with in-place tablespaces. - Mailing list pgsql-committers

From Kyotaro Horiguchi
Subject Re: pgsql: Fix pg_basebackup with in-place tablespaces.
Date
Msg-id 20220316.144216.300331926466543986.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: pgsql: Fix pg_basebackup with in-place tablespaces.  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: pgsql: Fix pg_basebackup with in-place tablespaces.  (David Steele <david@pgmasters.net>)
List pgsql-committers
At Wed, 16 Mar 2022 11:13:53 +1300, Thomas Munro <thomas.munro@gmail.com> wrote in 
> On Wed, Mar 16, 2022 at 10:28 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > David Steele <david@pgmasters.net> writes:
> > > On 3/14/22 19:31, Thomas Munro wrote:
> > >> Fix pg_basebackup with in-place tablespaces.
> >
> > > Perhaps I'm being picky, but seems like this logic should be wrapped in:
> > > if (allow_in_place_tablespaces)
> > > {
> > >      <...>
> > > }
> > > I worry about strange effects when this GUC is not enabled.
> >
> > What would happen if someone created an in-place tablespace and
> > then turned off the GUC?
> 
> Then it would break with unhelpful error messages.  I suppose we could
> error out explicitly, "in-place tablespace detected, but
> allow_in_place_tablespaces not enabled".  I'm not sure why we should
> suddenly choose to enforce that *here* though.

+1. The GUC is only to prevent non-developer users from accidentally
creating in-place tablespaces that is not officieally suported.  We
have done nothing about in-place tablespaces other than the things
needed to perform regression test, and I think we won't do that in
future.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-committers by date:

Previous
From: Thomas Munro
Date:
Subject: pgsql: Fix race between DROP TABLESPACE and checkpointing.
Next
From: Alexander Korotkov
Date:
Subject: pgsql: Fix default signature length for gist_ltree_ops