From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Steele <david(at)pgmasters(dot)net>, Thomas Munro <tmunro(at)postgresql(dot)org>, pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgsql: Fix pg_basebackup with in-place tablespaces. |
Date: | 2022-03-15 22:13:53 |
Message-ID: | CA+hUKG+sAx4edyX3290QmjBmKAwKcg1GOam50yqXwiVSMQowzg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On Wed, Mar 16, 2022 at 10:28 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> David Steele <david(at)pgmasters(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-03-16 00:01:46 | pgsql: Silence LLVM 14 API deprecation warnings. |
Previous Message | Tom Lane | 2022-03-15 21:28:23 | Re: pgsql: Fix pg_basebackup with in-place tablespaces. |