Re: standby recovery fails (tablespace related) (tentative patch and discussion) - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Date
Msg-id 20220722.092037.2223544132097441027.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: standby recovery fails (tablespace related) (tentative patch and discussion)  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: standby recovery fails (tablespace related) (tentative patch and discussion)
List pgsql-hackers
At Thu, 21 Jul 2022 23:14:57 +1200, Thomas Munro <thomas.munro@gmail.com> wrote in 
> On Thu, Jul 21, 2022 at 11:01 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > On 2022-Jul-20, Alvaro Herrera wrote:
> > > I see the following alternatives:
> > >
> > > 1. not backpatch this fix to 14 and older
> > > 2. use a different GUC; either allow_invalid_pages as previously
> > >    suggested, or create a new one just for this purpose
> > > 3. not provide any overriding mechanism in versions 14 and older
> >
> > I've got no opinions on this.  I don't like either 1 or 3, so I'm going
> > to add and backpatch a new GUC allow_recovery_tablespaces as the
> > override mechanism.
> >
> > If others disagree with this choice, please speak up.
> 
> Would it help if we back-patched the allow_in_place_tablespaces stuff?
>  I'm not sure how hard/destabilising that would be, but I could take a
> look tomorrow.

+1. Addiotional reason for me is it is a developer option.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Fwd: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS
Next
From: Justin Pryzby
Date:
Subject: Re: Expose Parallelism counters planned/execute in pg_stat_statements