From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | mr(dot)trubach(at)icloud(dot)com, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] Support systemd readiness notifications on reload |
Date: | 2024-08-28 09:01:22 |
Message-ID: | 73788299-43fc-4b70-b526-14e9e23e1773@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 26.08.24 18:03, mr(dot)trubach(at)icloud(dot)com wrote:
> This is my first time contribution to the PostgreSQL, so I’m not really
> familiar with the whole process. The attached patch adds basic support
> for Type=notify-reload systemd services, that is, sends readiness
> notifications on service reload. This allows waiting for postmaster
> reload to complete (note that child reloads still happen asynchronously
> and we don’t wait for them).
My understanding of this new notify-reload type is that it would allow
systemd to sequence configuration reloads that depend on each other.
But if we're only waiting for the postmaster reload to complete, are we
really satisfying that purpose?
It could be quite useful if we could somehow get the information that
all backends have completed a configuration reload, but that would
obviously be a much more complicated feature.
About the patch: For this purpose, I would not use
INSTR_TIME_SET_CURRENT(), which is too much of an abstraction, but use
clock_gettime(CLOCK_MONOTONIC) directly.
Also, there would need to be some documentation updates in
doc/src/sgml/runtime.sgml (but it's ok if the first patch version omits
that).
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2024-08-28 09:21:41 | json_query conditional wrapper bug |
Previous Message | Amit Kapila | 2024-08-28 09:00:13 | Re: Doc: fix the note related to the GUC "synchronized_standby_slots" |