Re: pgsql: Fix pg_basebackup with in-place tablespaces.
От | Kyotaro Horiguchi |
---|---|
Тема | Re: pgsql: Fix pg_basebackup with in-place tablespaces. |
Дата | |
Msg-id | 20220316.144216.300331926466543986.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Fix pg_basebackup with in-place tablespaces. (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: pgsql: Fix pg_basebackup with in-place tablespaces.
|
Список | 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 по дате отправления: