Re: [PATCH] Fix premature timeout in pg_promote() caused by signal interruptions - Mailing list pgsql-hackers

From Robert Pang
Subject Re: [PATCH] Fix premature timeout in pg_promote() caused by signal interruptions
Date
Msg-id CAJhEC05t1JHWEWtmji2u5n8g_+WmROuF5YuN7UEbOA=cL16zXQ@mail.gmail.com
Whole thread
In response to [PATCH] Fix premature timeout in pg_promote() caused by signal interruptions  (Robert Pang <robertpang@google.com>)
Responses Re: [PATCH] Fix premature timeout in pg_promote() caused by signal interruptions
List pgsql-hackers
Hi Michael and Tiancheng

On Tue, Mar 24, 2026 at 8:06 PM getiancheng_2012 <18663776784@163.com> wrote:
---- Replied Message ----
FromMichael Paquier<michael@paquier.xyz>
Date3/25/2026 10:28
ToRobert Pang<robertpang@google.com>
Ccpgsql-hackers<pgsql-hackers@postgresql.org>
SubjectRe: [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

pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: Refactor query normalization into core query jumbling
Next
From: Bertrand Drouvot
Date:
Subject: Re: Adding locks statistics