| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| Subject: | Re: injection_points: Switch wait/wakeup to use atomics rather than latches |
| Date: | 2026-05-30 04:13:47 |
| Message-ID: | ahpj-2ng4YN3cA0W@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 29, 2026 at 12:00:46PM -0400, Robert Haas wrote:
> On Fri, May 29, 2026 at 9:31 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> They only work after you have a PGPROC slot. If you want to inject code
>> to authentication, or into postmaster, you cannot use them.
>
> OK, got it now.
It seems like Heikki's comment was better worded than mine.
Also mentioned upthread, but the lack of PGPROC also means a lack of
monitoring as wait events cannot be tracked. Currently, we rely on
that in the TAP tests. For cases where the procs are not available, I
don't have a better idea than generating a LOG entry after the wait
counts have been generated (with a PID) and couple that with a poll of
the server logs to let a script understand that a process is in
waiting mode.
As a whole, I don't think that we should try to be fancy with the
implementation, which is why I have used primitives that should work
in any context, and I'm not convinced that this is worth its own
facility if that just means more responsiveness (in most cases the
wait should not take more than a couple ms to notice a wakeup). I'm
open to more fancy ideas, of course.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-05-30 04:17:44 | Re: [PATCH v1] Fix doubled-word typos and punctuation in code comments |
| Previous Message | Nisha Moond | 2026-05-30 02:49:15 | Re: Proposal: Conflict log history table for Logical Replication |