Re: standby recovery fails (tablespace related) (tentative patch and discussion)
От | Ibrar Ahmed |
---|---|
Тема | Re: standby recovery fails (tablespace related) (tentative patch and discussion) |
Дата | |
Msg-id | CALtqXTejpfCX7UF0D-OFUW6a5-ep3iqD2fj5xgy18yDqk1Hw4w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: standby recovery fails (tablespace related) (tentative patch and discussion) (Paul Guo <guopa@vmware.com>) |
Ответы |
Re: standby recovery fails (tablespace related) (tentative patch and discussion)
|
Список | 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 по дате отправления: