Re: [PATCH] Fix premature timeout in pg_promote() caused by signal interruptions

Hi Michael and Tiancheng

On Tue, Mar 24, 2026 at 8:06 PM getiancheng_2012 <18663776784(at)163(dot)com>
wrote:

> ---- Replied Message ----
> From Michael Paquier<michael(at)paquier(dot)xyz> <michael(at)paquier(dot)xyz>
> Date 3/25/2026 10:28
> To Robert Pang<robertpang(at)google(dot)com> <robertpang(at)google(dot)com>
> Cc pgsql-hackers<pgsql-hackers(at)postgresql(dot)org>
> <pgsql-hackers(at)postgresql(dot)org>
> Subject Re: [PATCH] Fix premature timeout in pg_promote() caused by
> signal interruptions
>
> On Wed, Mar 11, 2026 at 09:44:07AM -0700, Robert Pang wrote:
>
> The current implementation of pg_promote() calculates a fixed number
> of loop iterations based on the timeout value, assuming each loop
> waits exactly 100 ms for the backend latch. However, if the backend
> receives an unrelated signal (e.g., from
> client_connection_check_interval), it wakes up early. These repeated,
> unrelated wakeups cause the loop counter to deplete much faster than
> intended, leading to a premature timeout.
>
>
> It is true that we can do better here, and your proposal about having
> a more precise timeout calculation looks like a sensible improvement
> for this case.
>
> No objections regarding your patch. I would like to apply it on HEAD,
> if there are no objections.
> --
> Michael
>
>
> Hi all,
>
> Overall LGTM. Just a small comment:
>
> "+ end_time = GetCurrentTimestamp() + wait_seconds * 1000000L;"
>
> I think we can use TimestampTzPlusSeconds(GetCurrentTimestamp(), wait_seconds).
>
>
> Best regards
>
> Tiancheng Ge
>
>
Thank you for reviewing this patch. The use of TimestampTzPlusSeconds()
will be good.

Best regards
Robert Pang