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

From Ibrar Ahmed
Subject Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Date
Msg-id CALtqXTejpfCX7UF0D-OFUW6a5-ep3iqD2fj5xgy18yDqk1Hw4w@mail.gmail.com
Whole thread Raw
In response to Re: standby recovery fails (tablespace related) (tentative patch and discussion)  (Paul Guo <guopa@vmware.com>)
Responses Re: standby recovery fails (tablespace related) (tentative patch and discussion)  (Paul Guo <guopa@vmware.com>)
List pgsql-hackers


On Tue, Mar 30, 2021 at 12:12 PM Paul Guo <guopa@vmware.com> wrote:
On 2021/3/27, 10:23 PM, "Alvaro Herrera" <alvherre@2ndquadrant.com> wrote:

>    Hmm, can you post a rebased set, where the points under discussion
>   are marked in XXX comments explaining what the issue is?  This thread is
>    long and old ago that it's pretty hard to navigate the whole thing in
>    order to find out exactly what is being questioned.

OK. Attached are the rebased version that includes the change I discussed
in my previous reply. Also added POD documentation change for RecursiveCopy,
and modified the patch to use the backup_options introduced in
081876d75ea15c3bd2ee5ba64a794fd8ea46d794 for tablespace mapping.

>    I think 0004 can be pushed without further ado, since it's a clear and
>    simple fix.  0001 needs a comment about the new parameter in
>    RecursiveCopy's POD documentation.

Yeah, 0004 is no any risky. One concern seemed to be the compatibility of some
WAL dump/analysis tools(?). I have no idea about this. But if we do not backport
0004 we do not seem to need to worry about this.

>    As I understand, this is a backpatchable bug-fix.

Yes.

Thanks.

Patch does not apply successfully, 

Can you please rebase the patch.  


--
Ibrar Ahmed

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: enable_resultcache confusion
Next
From: Ibrar Ahmed
Date:
Subject: Re: Online verification of checksums