On 2021/3/27, 10:23 PM, "Alvaro Herrera" <alvhe...@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.
v11-0001-Support-node-initialization-from-backup-with-tab.patch
Description: v11-0001-Support-node-initialization-from-backup-with-tab.patch
v11-0002-Tests-to-replay-create-database-operation-on-sta.patch
Description: v11-0002-Tests-to-replay-create-database-operation-on-sta.patch
v11-0003-Fix-replay-of-create-database-records-on-standby.patch
Description: v11-0003-Fix-replay-of-create-database-records-on-standby.patch
v11-0004-Fix-database-create-drop-wal-description.patch
Description: v11-0004-Fix-database-create-drop-wal-description.patch