| 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.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
| 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 |