| From: | JoongHyuk Shin <sjh910805(at)gmail(dot)com> |
|---|---|
| To: | shihao zhong <zhong950419(at)gmail(dot)com> |
| Cc: | pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Add recovery boundary WAL record for database and tablespace commands |
| Date: | 2026-11-05 08:42:50 |
| Message-ID: | CACSdjfNo1CVKDTBRbuuZipv-4s2ozirv1Hjpace+q0iQfGiuug@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
>
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Add-recovery-boundary-WAL-record-for-database-and.patch | application/octet-stream | 15.0 KB |
| v2-0002-Make-recovery_min_apply_delay-wait-on-recovery-bo.patch | application/octet-stream | 5.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Xuneng Zhou | 2026-11-05 08:47:14 | Re: Preferred way to submit a very large batch of bugs? |
| Previous Message | Richard Guo | 2026-11-05 08:29:16 | Re: ERROR: too late to create a new PlaceHolderInfo |