[PATCH] Support systemd readiness notifications on reload
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t50177psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 11:40 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t50177_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t50177_1 && git checkout t50177_1Patchset v1 (message #1) is on t50177_1
Hi!
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).
—
Ivan
On 26.08.24 18:03, mr.trubach@icloud.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).