recoveryStopsAfter is not usable when recovery_target_inclusive is false

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

Responses

Browse pgsql-hackers by date

  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