Avoid unnecessary server restarts in the Kerberos TAP test
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:t253286psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 23, 2026 at 08:18 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 t253286_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 t253286_1 && git checkout t253286_1Patchset v1 (message #1) is on t253286_1
Hi,
While reading src/test/kerberos/t/001_auth.pl I noticed it restarts the
server after every configuration change, even though none of them needs a
restart. gss_accept_delegation is a PGC_SIGHUP parameter, and pg_hba.conf
and pg_ident.conf are re-read on SIGHUP, so a reload is sufficient in every
case. The rest of the authentication suite already relies on this, via the
reset_pg_hba() helper that reloads rather than restarts.
The attached patch replaces the seven restarts with reloads. The test
still passes here (142 tests) and is a little quicker, since it no longer
bounces the postmaster seven times.
Regards,
Ayush
On Mon, Aug 03, 2026 at 09:59:38AM +0530, Ayush Tiwari wrote:
While reading src/test/kerberos/t/001_auth.pl I noticed it restarts the
server after every configuration change, even though none of them needs a
restart. gss_accept_delegation is a PGC_SIGHUP parameter, and pg_hba.conf
and pg_ident.conf are re-read on SIGHUP, so a reload is sufficient in every
case. The rest of the authentication suite already relies on this, via the
reset_pg_hba() helper that reloads rather than restarts.The attached patch replaces the seven restarts with reloads. The test
still passes here (142 tests) and is a little quicker, since it no longer
bounces the postmaster seven times.
Wouldn't that be problematic for EXEC_BACKEND or WIN32, as the
configuration is passed down from a postmaster to the backends started
with their dedicated commands?
We have had quite a few discussions regarding the reload of ident and
hba rules when working on 004_file_inclusion.pl regarding that, FWIW,
and the limitations a reload involved in the scope of the TAP tests.
--
Michael
Hi,
On Mon, 3 Aug 2026 at 10:21, Michael Paquier <michael@paquier.xyz> wrote:
On Mon, Aug 03, 2026 at 09:59:38AM +0530, Ayush Tiwari wrote:
While reading src/test/kerberos/t/001_auth.pl I noticed it restarts the
server after every configuration change, even though none of them needs a
restart. gss_accept_delegation is a PGC_SIGHUP parameter, andpg_hba.conf
and pg_ident.conf are re-read on SIGHUP, so a reload is sufficient in
every
case. The rest of the authentication suite already relies on this, via
the
reset_pg_hba() helper that reloads rather than restarts.
The attached patch replaces the seven restarts with reloads. The test
still passes here (142 tests) and is a little quicker, since it no longer
bounces the postmaster seven times.Wouldn't that be problematic for EXEC_BACKEND or WIN32, as the
configuration is passed down from a postmaster to the backends started
with their dedicated commands?
Thanks Michael, I had overlooked the EXEC_BACKEND case.
Looking at it more closely, pg_hba.conf and pg_ident.conf appear to be
read by each EXEC_BACKEND child during authentication. The GUC changes
seem different, since the postmaster must first process the SIGHUP and
update the state used by new backends. As reload does not wait for that,
could the following connection race with the update? Is that the issue
you had in mind? (just for my understanding)
We have had quite a few discussions regarding the reload of ident and
hba rules when working on 004_file_inclusion.pl regarding that, FWIW,
and the limitations a reload involved in the scope of the TAP tests.
Given the small benefit, I think retaining the restarts is safer, so I
will withdraw the patch.
Regards,
Ayush