RE: BUG #19886: pg_terminate_backend timeout expires early after latch wakeups

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: "imchifan8(at)gmail(dot)com" <imchifan8(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: RE: BUG #19886: pg_terminate_backend timeout expires early after latch wakeups
Date: 2026-11-13 12:51:20
Message-ID: OS7PR01MB18317B8D66175540F0D4F0400F57F2@OS7PR01MB18317.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,
(Added Bharath in CC, who was an original author of the code)

Thanks for the report.

> The issue was reproduced on PostgreSQL 18.6 (Debian 18.6-1.pgdg13+2) on
> Linux/amd64. pg_wait_until_termination() subtracts the requested 100 ms wait
> interval after every WaitLatch return, even when the latch wakes before that
> interval has elapsed. The termination signal is still sent; callers can work
> around the premature synchronous return by polling for backend termination
> or retrying without unrelated latch traffic. This occurs when
> pg_terminate_backend waits with a positive timeout while unrelated signals
> repeatedly wake the caller's latch.

I think your analysis looks correct, but is it a realistic situation? IIUC this
can be addressed by calling GetCurrentTimestamp() in each loops, but it leads
system call per 100 ms. Not sure it can win the cost.

This was discussed once [1] but it was not addressed.

[1]: https://www.postgresql.org/message-id/CALj2ACXP35vCehvDZzx7F2bHphixdv%3DBTxf1HSuKwdwz2pTsuA%40mail.gmail.com

Best regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Langote 2026-11-13 13:28:32 Re: BUG #19851: Adding a tautological CHECK(true) to a domain changes JSON_VALUE's result (silent NULL, value/type c
Previous Message Nisha Moond 2026-11-13 11:32:34 Re: BUG #19892: Logical replication skips UPDATE/DELETE of rows with NULL in a hash-indexed subscriber column