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

From Paul Guo
Subject Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Date
Msg-id 6D2B8078-19FA-46CD-A12F-30C43F492D7A@vmware.com
Whole thread Raw
In response to Re: standby recovery fails (tablespace related) (tentative patch and discussion)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: standby recovery fails (tablespace related) (tentative patch and discussion)
List pgsql-hackers
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.


Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Idea: Avoid JOINs by using path expressions to follow FKs
Next
From: Julien Rouhaud
Date:
Subject: Re: Idea: Avoid JOINs by using path expressions to follow FKs