Avoid unnecessary server restarts in the Kerberos TAP test

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, 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?

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