Re: [PATCH] Prevent repeated deadlock-check signals in standby buffer pin waits

From: JoongHyuk Shin <sjh910805(at)gmail(dot)com>
To: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
Cc: assam258(at)gmail(dot)com, Ilmar Yunusov <tanswis42(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Prevent repeated deadlock-check signals in standby buffer pin waits
Date: 2026-06-28 10:05:53
Message-ID: CACSdjfM1Pb-kKf9=8eQ+6qnX-SNk_Cz7naZ2QRHk=y_wh2d59w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Henson,

Thanks for the careful read.

Both timeouts can be set in a single SIGALRM, since handle_sig_alarm() fires
every timeout that is already due. The if/else order is deliberate. The
delay
timeout is checked first because the cancel supersedes the deadlock check,
so
the both-set case resolves to the cancel, and no defensive branch is needed.

You're right about the coverage too. Only the delay > deadlock_timeout
regime
is exercised today, and -1 is the one where the second wait has no
startup-side
timer to fall back on. This patch will be rebased on top of the
deadlock-detector
fix that lands first, and I'll add a -1 regime test as part of that rebase.

--
JH Shin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Henson Choi 2026-06-28 10:12:22 Re: Row pattern recognition
Previous Message Pavlo Golub 2026-06-28 09:32:22 Re[2]: [PATCH v5] pg_stat_statements: Add last_execution_start column