Hi Shihao, Thanks for the review. I should have described the problem in more detail in my first message.
For now, I don't plan to handle the xid case in this patch, in code or in the docs. With the xid of DROP DATABASE and recovery_target_inclusive = off, recovery stops right before its commit record, as documented, but the changes DROP DATABASE makes before committing have been replayed by then. Recovery knows it has reached an xid target when it reads that transaction's commit record, so the operator can instead give the xid of a transaction known to have committed before DROP DATABASE started, with recovery_target_inclusive = on. Whether the docs should say this is a separate question. It is not specific to this patch or to xid targets, as an LSN target between those changes and the commit, with recovery_target_inclusive = off, leaves the same result on master. But a time target is different. Recovery knows it has passed a time target only when it reads a later timestamp, which on master comes only from commit and abort records, so the first one can be the commit of DROP DATABASE itself, after its changes have been replayed. The boundary record this patch adds gives recovery a timestamp ahead of those changes. v2 is only a rebase onto current master. -- JoongHyuk Shin >
v2-0001-Add-recovery-boundary-WAL-record-for-database-and.patch
Description: Binary data
v2-0002-Make-recovery_min_apply_delay-wait-on-recovery-bo.patch
Description: Binary data
