MIME-Version: 1.0
References: 
 <CAEdRop3fo784VmdeEWc3HXn-_x-tTx6AFXgNh78WGrhKkqvgtw@mail.gmail.com>
 <89846.1768373231@sss.pgh.pa.us>
In-Reply-To: <89846.1768373231@sss.pgh.pa.us>
From: Balkrishna Pandey <balkrishna.pandey@gmail.com>
Date: Wed, 14 Jan 2026 12:27:54 +0530
Message-ID: 
 <CAEdRop0j8cnDHhg26D8sSCu_FVfApcytsSiwKAfHubyHFji9qA@mail.gmail.com>
Subject: Re: Docs: Clarify that SIGHUP/reload does not update all GUCs for
 existing sessions
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-docs@lists.postgresql.org
Content-Type: multipart/alternative; boundary="00000000000034afcf064853a11a"
Archived-At: 
 <https://www.postgresql.org/message-id/CAEdRop0j8cnDHhg26D8sSCu_FVfApcytsSiwKAfHubyHFji9qA%40mail.gmail.com>
Precedence: bulk

--00000000000034afcf064853a11a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tom,

Thanks , that is a helpful framing, and I agree my first suggestion went
too deep into GUC =E2=80=9Ccontext=E2=80=9D details and still didn=E2=80=99=
t capture the full rule
(e.g., session-level SET overriding postgresql.conf).

What I was trying to address is the impression a reader may get from =E2=80=
=9Cso
that existing sessions also adopt the new values,=E2=80=9D namely that *all=
*
changed settings automatically take effect everywhere.

Based on your explanation, I think the doc should state the behavior at the
=E2=80=9Csource of active value=E2=80=9D level:

   -

   On SIGHUP, backends re-read postgresql.conf
   -

   A backend will only see a changed value take effect if it was previously
   using the value from postgresql.conf
   -

   If the active value came from elsewhere (e.g., a SET in the session,
   ALTER ROLE/DATABASE, etc.), then nothing changes in that session

Would something like the following be closer to the right level of
complexity?

   -

   The main server process also propagates this signal to all currently
   running server processes, so that existing sessions also adopt the new
   values (this will happen after they complete any currently-executing cli=
ent
   command).


   -

   The main server process also propagates this signal to all currently
   running server processes. After completing any currently-executing comma=
nd,
   existing sessions re-read postgresql.conf and will adopt changed values =
for
   parameters where their active setting was coming from postgresql.conf. I=
f a
   session=E2=80=99s active value was set from another source (for example,=
 a SET
   command or role/database settings), the session=E2=80=99s behavior will =
not change.

Does this phrasing align with what you had in mind? I appreciate your
feedback

Thanks in advance!

Regards,

Balkrishna

On Wed, Jan 14, 2026 at 12:17=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote=
:

> 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 no=
t+
> > 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
>

--00000000000034afcf064853a11a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div><p class=3D"gmail-isSelectedEnd">Hi Tom,</p><p cl=
ass=3D"gmail-isSelectedEnd">Thanks , that is a helpful framing, and I agree=
 my first suggestion went too deep into GUC =E2=80=9Ccontext=E2=80=9D detai=
ls and still didn=E2=80=99t capture the full rule (e.g., session-level SET =
overriding postgresql.conf).</p><p class=3D"gmail-isSelectedEnd">What I was=
 trying to address is the impression a reader may get from =E2=80=9Cso that=
 existing sessions also adopt the new values,=E2=80=9D namely that <em>all<=
/em> changed settings automatically take effect everywhere.</p><p class=3D"=
gmail-isSelectedEnd">Based on your explanation, I think the doc should stat=
e the behavior at the =E2=80=9Csource of active value=E2=80=9D level:</p><u=
l><li><p class=3D"gmail-isSelectedEnd">On SIGHUP, backends re-read postgres=
ql.conf</p></li><li><p class=3D"gmail-isSelectedEnd">A backend will only se=
e a changed value take effect if it was previously using the value from pos=
tgresql.conf</p></li><li><p class=3D"gmail-isSelectedEnd">If the active val=
ue came from elsewhere (e.g., a SET in the session, ALTER ROLE/DATABASE, et=
c.), then nothing changes in that session</p></li></ul><p class=3D"gmail-is=
SelectedEnd">Would something like the following be closer to the right leve=
l of complexity?</p><ul><li><p class=3D"gmail-isSelectedEnd">The main serve=
r process also propagates this signal to all currently running server proce=
sses, so that existing sessions also adopt the new values (this will happen=
 after they complete any currently-executing client command).</p></li></ul>=
<ul><li><p class=3D"gmail-isSelectedEnd">The main server process also propa=
gates this signal to all currently running server processes. After completi=
ng any currently-executing command, existing sessions re-read postgresql.co=
nf and will adopt changed values for parameters where their active setting =
was coming from postgresql.conf. If a session=E2=80=99s active value was se=
t from another source (for example, a SET command or role/database settings=
), the session=E2=80=99s behavior will not change.</p></li></ul><p>

Does this phrasing align with what you had in mind? I appreciate your feedb=
ack

</p><p>Thanks in advance!</p><p>Regards,</p><p>Balkrishna</p></div></div><b=
r><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=
=3D"gmail_attr">On Wed, Jan 14, 2026 at 12:17=E2=80=AFPM Tom Lane &lt;<a hr=
ef=3D"mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Balkrishna Pandey &lt;<a h=
ref=3D"mailto:balkrishna.pandey@gmail.com" target=3D"_blank">balkrishna.pan=
dey@gmail.com</a>&gt; writes:<br>
&gt; *Proposed wording (illustrative diff):*<br>
<br>
&gt; *+ The main server process also propagates this signal to all currentl=
y<br>
&gt; running server processes.+ Existing sessions will adopt new values for=
<br>
&gt; parameters whose context allows changes at reload+ time (for example,<=
br>
&gt; sighup). Parameters whose context is backend or superuser-backend do n=
ot+<br>
&gt; change within an already-started session; changes to those only affect=
<br>
&gt; subsequently-launched+ sessions.*<br>
<br>
This seems to me to be getting way too far into the implementation weeds,<b=
r>
while still failing to cover everything.=C2=A0 For example, it&#39;s also t=
rue<br>
that a SET within the session will override postgresql.conf.<br>
<br>
The main intent of the code is that SIGHUP will propagate a<br>
postgresql.conf change into an existing session if that session<br>
had been using the previous value from postgresql.conf.=C2=A0 If its<br>
source for the active value was something else, nothing changes.<br>
You can argue about whether &quot;backend&quot;-context GUCs are an excepti=
on<br>
to that rule, but I think our statement in the docs should be<br>
about at that level of complexity.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 regards, tom lane<br>
</blockquote></div>

--00000000000034afcf064853a11a--