From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
---|---|
To: | "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | recoveryStopsAfter is not usable when recovery_target_inclusive is false |
Date: | 2025-07-23 05:04:37 |
Message-ID: | OSCPR01MB14966AAAEF5C5D67C4DBDCB2CF55FA@OSCPR01MB14966.jpnprd01.prod.outlook.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi hackers,
While working on [1] I found the point. When recovery_target_lsn is specified and
recovery_target_inclusive is false, recoveryStopsAfter() cannot return true.
```
/* Check if the target LSN has been reached */
if (recoveryTarget == RECOVERY_TARGET_LSN &&
recoveryTargetInclusive &&
record->ReadRecPtr >= recoveryTargetLSN)
```
In this case the recovery can stop when next record is read. This normally works
well but if the next record has not been generated yet, startup process will wait
till new one will come then exit from the apply loop.
I feel the process can exit bit earliyer, by comparing with the end point of the
applied record and recovery_target_lsn.
Attached patch roughly implemented the idea.
I read the old discussions, but I cannot find the reason of current style.
Do you have any thoughts for it?
[1]: https://www.postgresql.org/message-id/flat/18897-d3db67535860dddb%40postgresql.org
Best regards,
Hayato Kuroda
FUJITSU LIMITED
Attachment | Content-Type | Size |
---|---|---|
recovery_stop_after.diffs | application/octet-stream | 1.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | TAKATSUKA Haruka | 2025-07-23 05:48:51 | Re: [Buildfarm:84] Re: stats.sql might fail due to shared buffers also used by parallel tests |
Previous Message | Amit Kapila | 2025-07-23 04:43:56 | Re: Question on any plans to use the User Server/User Mapping to provide Logical Replication Subscriptions the user/password in an encrypted manner |