| From: | JoongHyuk Shin <sjh910805(at)gmail(dot)com> |
|---|---|
| To: | joaovictor(dot)rito(at)gmail(dot)com |
| Cc: | shihao zhong <zhong950419(at)gmail(dot)com>, 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-12 11:58:20 |
| Message-ID: | CACSdjfMO5AtYSDWtJAEb-10D-JVsEJYqc4p==sd5fh12OWsmnw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi João,
Thanks for testing v2 and for the detailed report. v3 is attached.
On Wed, Nov 11, 2026 at 11:27 PM João Rito <joaovictor(dot)rito(at)gmail(dot)com>
wrote:
> 1. A time target between the boundary record and the commit record
> still breaks the database.
I don't plan to document this case. I'd expect an operator to take the
target from the statement's log_statement line, or from the last commit
before the command with recovery_target_inclusive = on, and with v3 both
stop before the command. A target that falls between the boundary record
and the commit behaves as it does on master, and covering it is not a
goal of this patch.
> 2. With recovery_target_inclusive = on and a target exactly equal to
> the boundary time, recovery does not stop at the boundary (the test
> is boundary_time > target), replays the file operation, and then
> stops before the commit because the commit time is later.
Agreed. The boundary record is not a transaction that
recovery_target_inclusive could include.
> 3. 0001 does not touch the documentation. The recovery_target_time
> and recovery_target_inclusive text in config.sgml (or the PITR
> chapter) does not mention that recovery now also stops before these
> commands, nor that xid and LSN targets are not covered (the xid
> case Shihao reported).
The recovery_target_inclusive entry is unchanged, for the reason given
in point 2. For xid and LSN targets I kept the docs as they are. As I
wrote to Shihao, the xid and LSN cases are not specific to this patch,
since master gives the same result. They are also not limited to
database commands. With recovery_target_xid set to a CREATE TABLE
transaction and recovery_target_inclusive = off, the table's file is
left behind.
> 4. Small thing about messages. "recovery stopping before recovery
> boundary, time ..." and the pg_waldump line do not say which
> command the boundary belongs to
Thanks for the suggestion. I kept the record to the time stamp, which
is all the stop check and the apply delay use. If others find the
command type useful, I can add it.
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0002-Make-recovery_min_apply_delay-wait-on-recovery-bo.patch | application/x-patch | 5.0 KB |
| v3-0001-Add-recovery-boundary-WAL-record-for-database-and.patch | application/x-patch | 15.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jan Nidzwetzki | 2026-11-12 12:22:38 | Re: improving handling of FPIs during recovery prefetching |
| Previous Message | Kirill Reshke | 2026-11-12 11:34:37 | Re: Internal error codes triggered by regression tests and user queries, take 2 |