Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vfuTJ-005ywn-3A for pgsql-docs@arkaria.postgresql.org; Wed, 14 Jan 2026 06:35:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vfuTJ-008I0m-0l for pgsql-docs@arkaria.postgresql.org; Wed, 14 Jan 2026 06:35:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vfrR6-007pIt-0o for pgsql-docs@lists.postgresql.org; Wed, 14 Jan 2026 03:20:44 +0000 Received: from mail-yx1-xb130.google.com ([2607:f8b0:4864:20::b130]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vfrR3-000JDU-2C for pgsql-docs@lists.postgresql.org; Wed, 14 Jan 2026 03:20:43 +0000 Received: by mail-yx1-xb130.google.com with SMTP id 956f58d0204a3-6467ac59e16so5959315d50.1 for ; Tue, 13 Jan 2026 19:20:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768360841; x=1768965641; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=LE0S45XoWPEKBkfkNsn87pv3fAUhfk7sg4lC/CVAPC4=; b=IRk9fnHYAsOC/xUMlyt4c7NHd02db+7Y50XlCzTf5eUFqe/spMCXlMUmsUVGATFaR4 LcjWvkpec1fWcywrtXan5itJsSiR38n+ssMZQ+5fz58OmdP310kMI86RfjGGdEz57qKG joglH+JccJF3SY/TTsTtFqcle2VatNHchbm18iA/KACh/dvIjVvQhydHMGlaIzJvZVfk SvVNMJIZz+KZluNbJlPB9lBxpqu2HEvZQ1w0LtZsiy12LL8gEyWsuEUT95M/UTvU6d5n HOv4kpJgf7LhSiOHXzZDw/69/D1vbgwRGqYeiKY1EfSXd9+GBHVYb7ovTnUoMrwA4Ml2 yL4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768360841; x=1768965641; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LE0S45XoWPEKBkfkNsn87pv3fAUhfk7sg4lC/CVAPC4=; b=vMyh0ipc70oSPAQHADrpifQf2mPycUUdhg2aqSVwBnuisO0IvineMVNENYLGUhXTjx HmQDCeNjgTWZ8Qc/MUyrNRY/BwQAZyQzzuYlXwbBwibDrSGkG8Ibwa8MmNeUPOEb3Rl3 y+HbhJvVr2F1sVkdRVxtRhI8Jkl9l9g+qxfXManGy2JHN5w4pS6S10u5XV/dIJ0uWcXO CA5NLQCsByLzz5vcJKgk7jkKbgpE9vqTtmX0hVP04+tc8pucvAx+QkfqDX9VycBA39cH o/gZ6/MLWIUa1AaUeWBJogsivl64TK8wLyNkaFiw/TnydqTATEI2d6DUqXljDQGQr16F 0JTA== X-Gm-Message-State: AOJu0YwvzqGdrAb2WNSpIYnQ/H7voEK/bq6/WIIofHBtsOZCeLsot421 fmEvofUBchD0giNq3E1aZWr1fB6njJjN5/xtB7CbEyhvYrK39kJgTEedGawbAfMMePXOOxIe6ls ulcBHMzw7bNLEZQB4j8kL6XFHjurdjlAVFo/X X-Gm-Gg: AY/fxX77N7VjoPSfP2Jm/Ss+YQOctvaLPS6yO93ewzeE59YSABOUv8oJDK2jL6H/qxm MODf1t8njp1oFdgU5jYCWAIfKTTVI0s5hJGV65RHw+QSMNprSO8owHCbe0hK+8DBXEu3YdtP43S Xhl3WHCOfB1m04yOC1TXwxf3NwH3jiwZO5dmZjPK9VbZL/ZjzCYPf3l17drFfwbh1KgpdAVj/QT IITrCrNnbCMqDibHmhlS+xnJ5w42QFeXNwqNBMu87fOV00xUyqi18iheDsnZlKwDBQGC+3PeDFJ L7TVld3mpf0qjeZTBm/IoBpQcxaycw== X-Received: by 2002:a05:690e:c43:b0:646:5127:acfb with SMTP id 956f58d0204a3-64901a9caefmr1450213d50.20.1768360841314; Tue, 13 Jan 2026 19:20:41 -0800 (PST) MIME-Version: 1.0 From: Balkrishna Pandey Date: Wed, 14 Jan 2026 08:50:31 +0530 X-Gm-Features: AZwV_QgHbdaVv1SND3LZz9nXDyvujMJkPehUZecrJSH5OIN4fsHdkzZTpy4OiuM Message-ID: Subject: Docs: Clarify that SIGHUP/reload does not update all GUCs for existing sessions To: pgsql-docs@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000c8053a06485097d4" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c8053a06485097d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, While reading the *=E2=80=9CServer Configuration=E2=80=9D* documentation, I= noticed a potentially misleading statement in: https://www.postgresql.org/docs/current/runtime-config.html (Chapter 19 =E2=86=92 19.1.2 =E2=80=9CParameter Interaction via the Configu= ration File=E2=80=9D) The text says that when the postmaster receives SIGHUP/reload, it propagates the signal to all server processes =E2=80=9Cso that existing ses= sions also adopt the new values=E2=80=9D. As written, this can be interpreted to mean that any changed parameter in postgresql.conf will be adopted by already-connected sessions after a reload. However, many GUCs have context =E2=80=9Cbackend=E2=80=9D or =E2=80= =9Csuperuser-backend=E2=80=9D and do not change within an already-started session; those changes only affect subsequently-launched sessions. *Suggestion*: qualify the sentence to indicate that existing sessions will pick up changes only for parameters whose context allows it (e.g., =E2=80=9Csighup=E2=80=9D), and that =E2=80=9Cbackend=E2=80=9D / =E2=80=9Csu= peruser-backend=E2=80=9D settings won=E2=80=99t change for existing sessions. *Proposed wording (illustrative diff):* *"* *- 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 client command).* *+ 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.* " Happy to send a formal patch if you would like. Thanks, Balkrishna --000000000000c8053a06485097d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello,

While reading the =E2=80=9CServer Configuration= =E2=80=9D documentation, I noticed a potentially misleading statement i= n:

https://www.postgresql.o= rg/docs/current/runtime-config.html
(Chapter 19 =E2=86=92 19.1.2 =E2= =80=9CParameter Interaction via the Configuration File=E2=80=9D)

The text says that when the postmaster receives S= IGHUP/reload, it propagates the signal to all server processes =E2=80=9Cso = that existing sessions also adopt the new values=E2=80=9D.

As written, this can be interpreted to mean that any ch= anged parameter in postgresql.conf will be adopted by already-connected ses= sions after a reload. However, many GUCs have context =E2=80=9Cbackend=E2= =80=9D or =E2=80=9Csuperuser-backend=E2=80=9D and do not change within an a= lready-started session; those changes only affect subsequently-launched ses= sions.

Suggestion: qualif= y the sentence to indicate that existing sessions will pick up changes only= for parameters whose context allows it (e.g., =E2=80=9Csighup=E2=80=9D), a= nd that =E2=80=9Cbackend=E2=80=9D / =E2=80=9Csuperuser-backend=E2=80=9D set= tings won=E2=80=99t change for existing sessions.

Proposed wording (illustrative diff):

"

= - The main server process also propagates this signal to all currently r= unning server processes,

- so th= at existing sessions also adopt the new values (this will happen after they= complete any
- currently-executing client command).


+ The main server process also propag= ates this signal to all currently running server processes.
+ Existing s= essions will adopt new values for parameters whose context allows changes a= t reload
+ time (for example, sighup). Parameters whose context is backe= nd or superuser-backend do not
+ change within an already-started sessio= n; changes to those only affect subsequently-launched
+ sessions.

"

Happy to send a formal patch if you would like.


= Thanks,
Balkrishna=C2=A0

--000000000000c8053a06485097d4--