From: Tom Lane <tgl@sss.pgh.pa.us>
To: Balkrishna Pandey <balkrishna.pandey@gmail.com>
cc: pgsql-docs@lists.postgresql.org
Subject: Re: Docs: Clarify that SIGHUP/reload does not update all GUCs for
 existing sessions
In-reply-to: 
 <CAEdRop3fo784VmdeEWc3HXn-_x-tTx6AFXgNh78WGrhKkqvgtw@mail.gmail.com>
References: 
 <CAEdRop3fo784VmdeEWc3HXn-_x-tTx6AFXgNh78WGrhKkqvgtw@mail.gmail.com>
Comments: In-reply-to Balkrishna Pandey <balkrishna.pandey@gmail.com>
	message dated "Wed, 14 Jan 2026 08:50:31 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <89845.1768373231.1@sss.pgh.pa.us>
Date: Wed, 14 Jan 2026 01:47:11 -0500
Message-ID: <89846.1768373231@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/89846.1768373231%40sss.pgh.pa.us>
Precedence: bulk

Balkrishna Pandey <balkrishna.pandey@gmail.com> writes:
> *Proposed wording (illustrative diff):*

> *+ The main server process also propagates this signal to all currently
> running server processes.+ Existing sessions will adopt new values for
> parameters whose context allows changes at reload+ time (for example,
> sighup). Parameters whose context is backend or superuser-backend do not+
> change within an already-started session; changes to those only affect
> subsequently-launched+ sessions.*

This seems to me to be getting way too far into the implementation weeds,
while still failing to cover everything.  For example, it's also true
that a SET within the session will override postgresql.conf.

The main intent of the code is that SIGHUP will propagate a
postgresql.conf change into an existing session if that session
had been using the previous value from postgresql.conf.  If its
source for the active value was something else, nothing changes.
You can argue about whether "backend"-context GUCs are an exception
to that rule, but I think our statement in the docs should be
about at that level of complexity.

			regards, tom lane