MIME-Version: 1.0
From: Robert Pang <robertpang@google.com>
Date: Wed, 11 Mar 2026 09:44:07 -0700
Message-ID: 
 <CAJhEC07OK8J7tLUbyiccnuOXRE7UKxBNqD2-pLfeFXa=tBoWtw@mail.gmail.com>
Subject: [PATCH] Fix premature timeout in pg_promote() caused by signal
 interruptions
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/mixed; boundary="000000000000ed0bed064cc25853"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJhEC07OK8J7tLUbyiccnuOXRE7UKxBNqD2-pLfeFXa%3DtBoWtw%40mail.gmail.com>
Precedence: bulk

--000000000000ed0bed064cc25853
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

We have observed an issue where pg_promote() returns false and issues
a timeout warning prematurely, even if the standby server is
successfully promoted later within the specified timeout period.

Problem Description

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.

Reproduction

Set up a standby server while modifying pg_promote not to write the
promote file to block the promotion. And by setting
client_connection_check_interval =3D 1, we can consistently trigger a
premature timeout. In the example below, a 10-second timeout expires
in roughly 107 ms:

postgres=3D# set client_connection_check_interval=3D1;
SET
postgres=3D# \timing
Timing is on.
postgres=3D# select pg_promote(true, 10);
WARNING:  server did not promote within 10 seconds
=E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90
=E2=94=82 pg_promote =E2=94=82
=E2=94=9C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=A4
=E2=94=82 f          =E2=94=82
=E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98
(1 row)

Time: 107.783 ms

Proposed Fix

The attached patch modifies the logic to loop based on the actual
elapsed time rather than a fixed number of iterations. This ensures
that pg_promote() respects the specified timeout regardless of how
many times the backend latch is signaled.

After applying the patch, the timeout behaves as expected:

postgres=3D# set client_connection_check_interval=3D1;
SET
postgres=3D# \timing
Timing is on.
postgres=3D# select pg_promote(true, 10);
WARNING:  server did not promote within 10 seconds
=E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90
=E2=94=82 pg_promote =E2=94=82
=E2=94=9C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=A4
=E2=94=82 f          =E2=94=82
=E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98
(1 row)

Time: 10000.865 ms (00:10.001)

We would like to submit this patch for the community's consideration.

Best regards
Robert Pang
Google

--000000000000ed0bed064cc25853
Content-Type: application/x-patch;
	name="0001-Fix-premature-timeout-in-pg_promote-caused-by-signal.patch"
Content-Disposition: attachment;
	filename="0001-Fix-premature-timeout-in-pg_promote-caused-by-signal.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mmm9ilbh0>
X-Attachment-Id: f_mmm9ilbh0

RnJvbSAyMDc1YWVjZGNjNmE3MGZlYTFiMzNjOWU5MDg3OGU5MGMyYTYxNjEyIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBSb2JlcnQgUGFuZyA8cm9iZXJ0cGFuZ0Bnb29nbGUuY29tPgpE
YXRlOiBUdWUsIDEwIE1hciAyMDI2IDIxOjExOjQ5IC0wNzAwClN1YmplY3Q6IFtQQVRDSF0gRml4
IHByZW1hdHVyZSB0aW1lb3V0IGluIHBnX3Byb21vdGUoKSBjYXVzZWQgYnkgc2lnbmFsCiBpbnRl
cnJ1cHRpb25zCgpQcmV2aW91c2x5LCBwZ19wcm9tb3RlKCkgbG9vcGVkIGEgZml4ZWQgbnVtYmVy
IG9mIHRpbWVzIGNhbGN1bGF0ZWQgZnJvbSB0aGUKc3BlY2lmaWVkIHRpbWVvdXQgYW5kIHdhaXRl
ZCAxMDAgbXMgb24gdGhlIGJhY2tlbmQgbGF0Y2ggcGVyIGl0ZXJhdGlvbiBmb3IKc3RhbmRieSBw
cm9tb3Rpb24uIEhvd2V2ZXIsIHVucmVsYXRlZCBzaWduYWxzIHRvIHRoZSBiYWNrZW5kIGNvdWxk
IHNldCB0aGUKbGF0Y2ggYW5kIHdha2UgdXAgdGhlIGJhY2tlbmQgZWFybHksIHJlc3VsdGluZyBp
biBhIHdhaXQgdGltZSBzaWduaWZpY2FudGx5CnNob3J0ZXIgdGhhbiB0aGUgc3BlY2lmaWVkIHRp
bWVvdXQgaWYgdGhlIHNpZ25hbHMgaGFwcGVuZWQgZnJlcXVlbnRseS4KClRoaXMgY29tbWl0IHJl
ZmluZXMgdGhlIGxvZ2ljIHRvIHRyYWNrIGFjdHVhbCBlbGFwc2VkIHRpbWUuIEJ5IGxvb3Bpbmcg
dW50aWwgdGhlCnJlcXVlc3RlZCBkdXJhdGlvbiBoYXMgdHJ1bHkgcGFzc2VkLCBwZ19wcm9tb3Rl
KCkgbm93IGVuc3VyZXMgdGhhdCB0aGUgd2FpdCBkb2VzCm5vdCBlbmQgcHJlbWF0dXJlbHkgZHVl
IHRvIHNpZ25hbHMuCgpBdXRob3I6IFJvYmVydCBQYW5nCi0tLQogc3JjL2JhY2tlbmQvYWNjZXNz
L3RyYW5zYW0veGxvZ2Z1bmNzLmMgfCA4ICsrKystLS0tCiAxIGZpbGUgY2hhbmdlZCwgNCBpbnNl
cnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2FjY2Vz
cy90cmFuc2FtL3hsb2dmdW5jcy5jIGIvc3JjL2JhY2tlbmQvYWNjZXNzL3RyYW5zYW0veGxvZ2Z1
bmNzLmMKaW5kZXggZWNiM2M4YzA4MjAuLjYxMzdhZjJkMzVlIDEwMDY0NAotLS0gYS9zcmMvYmFj
a2VuZC9hY2Nlc3MvdHJhbnNhbS94bG9nZnVuY3MuYworKysgYi9zcmMvYmFja2VuZC9hY2Nlc3Mv
dHJhbnNhbS94bG9nZnVuY3MuYwpAQCAtNjkwLDcgKzY5MCw3IEBAIHBnX3Byb21vdGUoUEdfRlVO
Q1RJT05fQVJHUykKIAlib29sCQl3YWl0ID0gUEdfR0VUQVJHX0JPT0woMCk7CiAJaW50CQkJd2Fp
dF9zZWNvbmRzID0gUEdfR0VUQVJHX0lOVDMyKDEpOwogCUZJTEUJICAgKnByb21vdGVfZmlsZTsK
LQlpbnQJCQlpOworCVRpbWVzdGFtcFR6CWVuZF90aW1lOwogCiAJaWYgKCFSZWNvdmVyeUluUHJv
Z3Jlc3MoKSkKIAkJZXJlcG9ydChFUlJPUiwKQEAgLTczMSw4ICs3MzEsOCBAQCBwZ19wcm9tb3Rl
KFBHX0ZVTkNUSU9OX0FSR1MpCiAJCVBHX1JFVFVSTl9CT09MKHRydWUpOwogCiAJLyogd2FpdCBm
b3IgdGhlIGFtb3VudCBvZiB0aW1lIHdhbnRlZCB1bnRpbCBwcm9tb3Rpb24gKi8KLSNkZWZpbmUg
V0FJVFNfUEVSX1NFQ09ORCAxMAotCWZvciAoaSA9IDA7IGkgPCBXQUlUU19QRVJfU0VDT05EICog
d2FpdF9zZWNvbmRzOyBpKyspCisJZW5kX3RpbWUgPSBHZXRDdXJyZW50VGltZXN0YW1wKCkgKyB3
YWl0X3NlY29uZHMgKiAxMDAwMDAwTDsKKwl3aGlsZSAoR2V0Q3VycmVudFRpbWVzdGFtcCgpIDwg
ZW5kX3RpbWUpCiAJewogCQlpbnQJCQlyYzsKIApAQCAtNzQ1LDcgKzc0NSw3IEBAIHBnX3Byb21v
dGUoUEdfRlVOQ1RJT05fQVJHUykKIAogCQlyYyA9IFdhaXRMYXRjaChNeUxhdGNoLAogCQkJCQkg
ICBXTF9MQVRDSF9TRVQgfCBXTF9USU1FT1VUIHwgV0xfUE9TVE1BU1RFUl9ERUFUSCwKLQkJCQkJ
ICAgMTAwMEwgLyBXQUlUU19QRVJfU0VDT05ELAorCQkJCQkgICAxMDBMLAogCQkJCQkgICBXQUlU
X0VWRU5UX1BST01PVEUpOwogCiAJCS8qCi0tIAoyLjUzLjAuNDczLmc0YTc5NThjYTE0LWdvb2cK
Cg==
--000000000000ed0bed064cc25853--