[PATCH] Add ALTER SYSTEM RELOAD

On 23/09/2026 11:44, Yuhang Qiu wrote:

Hi hackers,

For configuration parameters that can be reloaded, administrators often need
to perform two steps in succession:
```sql
ALTER SYSTEM SET work_mem = '64MB';
SELECT pg_reload_conf();
```

I propose adding `ALTER SYSTEM RELOAD`, so the sequence can be written as:
```sql
ALTER SYSTEM SET work_mem = '64MB';
ALTER SYSTEM RELOAD;
```

I think this is a good idea.

I think log rotation (`ALTER SYSTEM ROTATE LOG`) and standby promotion
(`ALTER SYSTEM PROMOTE`) are also promising directions for this command family.
This patch proposes only `RELOAD`. I would appreciate feedback on whether
`ALTER SYSTEM` is the right place for this operation.

I like those ideas as well.

--

Vik Fearing

On Sep 23, 2026, at 17:44, Yuhang Qiu <iamqyh@gmail.com> wrote:

Hi hackers,

For configuration parameters that can be reloaded, administrators often need
to perform two steps in succession:
```sql
ALTER SYSTEM SET work_mem = '64MB';
SELECT pg_reload_conf();
```

I propose adding `ALTER SYSTEM RELOAD`, so the sequence can be written as:
```sql
ALTER SYSTEM SET work_mem = '64MB';
ALTER SYSTEM RELOAD;
```

`ALTER SYSTEM` is already the SQL interface for changing server configuration,
and reloading is a common next step. Keeping both steps in the same command
family would make the workflow easier to discover, without requiring users to
find a separate function for the second step. I also think `ALTER SYSTEM` is a
more natural interface for administrative operations than function calls.
`pg_reload_conf()` would remain available.

The privilege difference is a possible concern: this patch requires a
superuser for `ALTER SYSTEM RELOAD`, while `pg_reload_conf()` can be granted to
other roles. I am unsure whether this divergence would be acceptable. The new
command cannot run inside a transaction block, but I consider this a benefit: a
reload request cannot be rolled back.

In my experience with `psql`, commands are also easier to complete with Tab;
I cannot complete the function call in the same way. Adding `RELOAD` means
that `RE` will match both `RELOAD` and `RESET`, so the `RE` prefix will no
longer uniquely complete either command. Even with that drawback, I find the
command form more convenient overall.

I think log rotation (`ALTER SYSTEM ROTATE LOG`) and standby promotion
(`ALTER SYSTEM PROMOTE`) are also promising directions for this command family.
This patch proposes only `RELOAD`. I would appreciate feedback on whether
`ALTER SYSTEM` is the right place for this operation.

Best regards,
Yuhang Qiu

<0001-Add-ALTER-SYSTEM-RELOAD.patch>

Thanks for the patch. After reading it, I have a concern. pg_reload_conf() relies on normal function privileges, so a super user can grant EXECUTE on it to a non-superuser. With this patch, the two interfaces for doing essentially the same thing would have different privilege models:

```
GRANT EXECUTE ON FUNCTION pg_reload_conf() TO some-user;

-- allowed
SELECT pg_reload_conf();

-- not allowed
ALTER SYSTEM RELOAD;
```

Is there a reason ALTER SYSTEM RELOAD needs stronger privileges than pg_reload_conf()?

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Hi,

On Thu, Sep 24, 2026 at 03:39:22PM +0800, Chao Li wrote:

Is there a reason ALTER SYSTEM RELOAD needs stronger privileges than
pg_reload_conf()?

Well, it is clear that you won't be able to GRANT this on a SQL-level.

But what could be done is add the pg_maintain (or something similar)
default role as an allowed user for running this command besides
Superuser.

Michael

Hi,

On Thu, Sep 24, 2026 at 03:39:22PM +0800, Chao Li wrote:

Is there a reason ALTER SYSTEM RELOAD needs stronger privileges than
pg_reload_conf()?

Well, it is clear that you won't be able to GRANT this on a SQL-level.

But what could be done is add the pg_maintain (or something similar)
default role as an allowed user for running this command besides
Superuser.

Michael

On Sep 24, 2026, at 17:35, Michael Banck <mbanck@gmx.net> wrote:

Hi,

On Thu, Sep 24, 2026 at 03:39:22PM +0800, Chao Li wrote:

Is there a reason ALTER SYSTEM RELOAD needs stronger privileges than
pg_reload_conf()?

Well, it is clear that you won't be able to GRANT this on a SQL-level.

But what could be done is add the pg_maintain (or something similar)
default role as an allowed user for running this command besides
Superuser.

Michael

Yeah, that could be a solution. But the current patch only allows super user:
```
+/*
+ * Execute ALTER SYSTEM RELOAD.
+ */
+void
+AlterSystemReloadConfig(void)
+{
+	if (!AllowAlterSystem)
+		ereport(ERROR,
+				(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+				 errmsg("ALTER SYSTEM is not allowed in this environment")));
+
+	if (!superuser())
+		ereport(ERROR,
+				(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
+				 errmsg("permission denied to perform ALTER SYSTEM RELOAD")));
+
+	if (kill(PostmasterPid, SIGHUP))
+		ereport(ERROR,
+				(errmsg("failed to send signal to postmaster: %m")));
+}
```

That’s what I got the concern.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

On 24 Sep 2026, at 13:38, Chao Li <li.evan.chao@gmail.com> wrote:

Yeah, that could be a solution. But the current patch only allows super user:

+ if (!superuser())
+ ereport(ERROR,
+ (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
+ errmsg("permission denied to perform ALTER SYSTEM RELOAD")));

I don't have a strong opinion either way, but if this check remains the error
message we commonly use is "must be superuser to ..."

--
Daniel Gustafsson

On Thu, Sep 24, 2026 at 11:35:23AM +0200, Michael Banck wrote:

But what could be done is add the pg_maintain (or something similar)
default role as an allowed user for running this command besides
Superuser.

+1, pg_maintain seems reasonable here.

Regarding the patch itself:

	+typedef enum AlterSystemAction
	+{
	+       ALTER_SYSTEM_SET,
	+       ALTER_SYSTEM_RESET,
	+       ALTER_SYSTEM_RELOAD
	+} AlterSystemAction;

What's the reason for separating SET and RESET once more? They're already
differentiated via setstmt->kind, aren't they?

Chao Li <li.evan.chao@gmail.com> writes:

On Sep 23, 2026, at 17:44, Yuhang Qiu <iamqyh@gmail.com> wrote:
For configuration parameters that can be reloaded, administrators often need
to perform two steps in succession:
```sql
ALTER SYSTEM SET work_mem = '64MB';
SELECT pg_reload_conf();
```

I propose adding `ALTER SYSTEM RELOAD`, so the sequence can be written as:
```sql
ALTER SYSTEM SET work_mem = '64MB';
ALTER SYSTEM RELOAD;
```

Thanks for the patch. After reading it, I have a concern. pg_reload_conf() relies on normal function privileges, so a super user can grant EXECUTE on it to a non-superuser. With this patch, the two interfaces for doing essentially the same thing would have different privilege models:

I'm pretty down on this proposal even without the privilege question.
"There's more than one way to do it" isn't a great thing for
security-relevant operations, and this surely is one.

Also, I don't like the loss of an explainable scope for what
ALTER SYSTEM does. I see the patch changes the command's summary
like so:

   <refname>ALTER SYSTEM</refname>
-  <refpurpose>change a server configuration parameter</refpurpose>
+  <refpurpose>change or reload the server configuration</refpurpose>

which is entirely not self-consistent. (For one thing, it implies
that you can change any part of the server's configuration through
this command, which is not so: stuff like pg_hba.conf remains out
of scope.)

This lack of intellectual consistency would get ten times worse
if we followed through on the idea of overloading ALTER SYSTEM
with unrelated actions like log rotation and promotion.

The reason ALTER SYSTEM exists, IMO, is to re-use the infrastructure
we had for SET and RESET commands to allow alteration of GUC values
system-wide as well as locally in a session. It does not exist for
discoverability.

regards, tom lane

On 9/24/26 9:29 PM, Tom Lane wrote:

Chao Li <li.evan.chao@gmail.com> writes:

On Sep 23, 2026, at 17:44, Yuhang Qiu <iamqyh@gmail.com> wrote:
For configuration parameters that can be reloaded, administrators often need
to perform two steps in succession:
```sql
ALTER SYSTEM SET work_mem = '64MB';
SELECT pg_reload_conf();
```

I propose adding `ALTER SYSTEM RELOAD`, so the sequence can be written as:
```sql
ALTER SYSTEM SET work_mem = '64MB';
ALTER SYSTEM RELOAD;
```

Thanks for the patch. After reading it, I have a concern. pg_reload_conf() relies on normal function privileges, so a super user can grant EXECUTE on it to a non-superuser. With this patch, the two interfaces for doing essentially the same thing would have different privilege models:

I'm pretty down on this proposal even without the privilege question.
"There's more than one way to do it" isn't a great thing for
security-relevant operations, and this surely is one.

+1

I do not see how this adds anything worth the increased maintenance
burden. How to reload the config is clearly discoverable in the docs for
ALTER SYSTEM.

Andreas

Hi all,

Sorry for the late reply.

The v1 patch was mainly intended to discuss whether `RELOAD` belongs
under `ALTER SYSTEM`, so I did not cover the privilege design in detail.
I had in mind a separate ACL for `ALTER SYSTEM` operations, allowing
privileges to be granted per operation. If we add more operations,
predefined roles may be too broad to allow fine-grained control.

I'm pretty down on this proposal even without the privilege question.
"There's more than one way to do it" isn't a great thing for
security-relevant operations, and this surely is one.

Also, I don't like the loss of an explainable scope for what
ALTER SYSTEM does.

I agree with Tom's concerns about adding a second interface and blurring
the scope of the command. I also agree with Andreas about the maintenance
cost. `pg_reload_conf()` already provides the reload operation, and the
`ALTER SYSTEM` documentation explains how to request a reload.

This lack of intellectual consistency would get ten times worse
if we followed through on the idea of overloading ALTER SYSTEM
with unrelated actions like log rotation and promotion.

Agreed. Log rotation and promotion were simply the first operations that
came to mind as possible fits for a broader command family. Adding just
those two would not give ALTER SYSTEM a coherent scope. Oracle has a much
broader ALTER SYSTEM command family, though. If PostgreSQL developed a
similarly broad family of instance-level operations, could that give the
command a clearer scope? But still, it would increase the overlap with
existing functions that concerns Tom, as well as the maintenance cost
Andreas noted.

Thanks everyone for the reviews.

Best regards,
Yuhang Qiu