Improving display of octal GUCs
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t248695psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 07, 2026 at 06:07 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t248695_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t248695_1 && git checkout t248695_1Patchset v1 (message #1) is on t248695_1
It's customary to write the values of unix_socket_permissions
and a few other GUCs in octal. However, we implemented that
via show_hooks, which don't affect any pg_settings columns
except the current value. So you get results like this:
regression=# SELECT name,setting,min_val,max_val,boot_val,reset_val
FROM pg_settings
WHERE name IN ('data_directory_mode', 'log_file_mode', 'unix_socket_permissions');
name | setting | min_val | max_val | boot_val | reset_val
-------------------------+---------+---------+---------+----------+-----------
data_directory_mode | 0700 | 0 | 511 | 448 | 448
log_file_mode | 0600 | 0 | 511 | 384 | 384
unix_socket_permissions | 0777 | 0 | 511 | 511 | 511
(3 rows)
That's always been a niggling annoyance, and we recently got a bug
report complaining about it [1]/messages/by-id/19540-e641040b089ab768@postgresql.org. So here's an attempt to improve
matters:
regression=# SELECT name,setting,min_val,max_val,boot_val,reset_val
FROM pg_settings
WHERE name IN ('data_directory_mode', 'log_file_mode', 'unix_socket_permissions');
name | setting | min_val | max_val | boot_val | reset_val
-------------------------+---------+---------+---------+----------+-----------
data_directory_mode | 0700 | 0000 | 0777 | 0700 | 0700
log_file_mode | 0600 | 0000 | 0777 | 0600 | 0600
unix_socket_permissions | 0777 | 0000 | 0777 | 0777 | 0777
(3 rows)
Details in the draft commit message.
regards, tom lane
On Tue, Jun 30, 2026 at 5:32 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
regression=# SELECT name,setting,min_val,max_val,boot_val,reset_val
FROM pg_settings
WHERE name IN ('data_directory_mode', 'log_file_mode', 'unix_socket_permissions');
name | setting | min_val | max_val | boot_val | reset_val
-------------------------+---------+---------+---------+----------+-----------
data_directory_mode | 0700 | 0000 | 0777 | 0700 | 0700
log_file_mode | 0600 | 0000 | 0777 | 0600 | 0600
unix_socket_permissions | 0777 | 0000 | 0777 | 0777 | 0777
(3 rows)Details in the draft commit message.
Nice, the patch lgtm.
--
Fabrízio de Royes Mello
Hi,
regression=# SELECT name,setting,min_val,max_val,boot_val,reset_val
FROM pg_settings
WHERE name IN ('data_directory_mode', 'log_file_mode',
'unix_socket_permissions');
name | setting | min_val | max_val | boot_val |
reset_val
-------------------------+---------+---------+---------+----------+-----------
data_directory_mode | 0700 | 0000 | 0777 | 0700 | 0700
log_file_mode | 0600 | 0000 | 0777 | 0600 | 0600
unix_socket_permissions | 0777 | 0000 | 0777 | 0777 | 0777
(3 rows)Details in the draft commit message.
I tested the patch locally and found no functional issue. LGTM.
One minor note: I considered whether check_GUC_init() should
validate GUC_SHOW_IN_OCTAL (e.g. not allowing it together with a
show_hook, or with other flags). But some GUCs intentionally use a
show_hook, and check_GUC_init() validates only a few combinations
today, so I don't think it's necessary here.
Regards,
Tatsuya Kawata
Tatsuya Kawata <kawatatatsuya0913@gmail.com> writes:
One minor note: I considered whether check_GUC_init() should
validate GUC_SHOW_IN_OCTAL (e.g. not allowing it together with a
show_hook, or with other flags). But some GUCs intentionally use a
show_hook, and check_GUC_init() validates only a few combinations
today, so I don't think it's necessary here.
Yeah, I think there actually could be a use-case for having a
show_hook along with GUC_SHOW_IN_OCTAL: if you want the value shown in
octal but the calculation of the effective value is more complicated
than just "show the variable". So I don't want to reject that.
Perhaps there's a case for checking that GUC_SHOW_IN_OCTAL isn't
applied to a non-integer GUC, but I can't get too excited about that.
regards, tom lane
Hi Tom,
I built v1 on current master and tested it -- the display is consistent now:
pg_settings shows setting/min_val/max_val/boot_val/reset_val all in octal for
the three mode GUCs, and SHOW / current_setting agree. The out-of-range error
comes out in octal too (ALTER SYSTEM SET log_file_mode = 0640 -> "01200 is
outside the valid range ... (0000 .. 0777)"). The new flag bit (0x010000) is
the first free one below the unit flags, no collision. make check is green.
I also checked that dropping the show_hooks doesn't change "postgres -C": it
still prints decimal (511), but that's not a regression -- GetConfigOption()
already formatted PGC_INT with %d and never went through the show_hook, so -C
was decimal before too. Matches your note about GetConfigOption() being out
of scope.
One optional thought on that range error: since an unquoted 0640 is decimal
640 in SQL (not octal), the "01200" can be a little surprising to someone who
meant octal -- the value they typed and the value echoed back don't visibly
line up. A small errhint might smooth that over without reintroducing decimal
into the message, e.g.
ERROR: 01200 is outside the valid range for parameter "log_file_mode"
(0000 .. 0777)
HINT: To specify an octal value, quote it, e.g. '0640'.
Fully optional, and it does edge toward input handling rather than display, so
feel free to ignore.
LGTM.
Regards,
Rui
Hi Tom,
Perhaps there's a case for checking that GUC_SHOW_IN_OCTAL isn't
applied to a non-integer GUC, but I can't get too excited about that.
I think this is worth doing because the flag is available to extensions. I
would also require a nonnegative integer range, or define signed formatting:
with the current %o, -1 is typically shown as 037777777777 on machines with
32-bit int. All three GUCs marked GUC_SHOW_IN_OCTAL by this patch already
have a minimum of zero.
I wondered whether an octal-only flag would paint us into a corner. I could
not find any GUC customarily displayed in hexadecimal. Accepting hexadecimal
input is a different matter, since the input radix is not retained. So I see
no reason for a more general display-base abstraction until another use
appears.
Maybe the new regression test query against pg_settings could also include
setting and reset_val, as in the opening example. The former would exercise
the replacement of the old show hooks, while the latter is the only changed
auxiliary value that the test does not currently check.
With those small changes, the patch looks ready for committer.
Best regards, Andrey Borodin.
Andrey Borodin <x4mmm@yandex-team.ru> writes:
I think this is worth doing because the flag is available to extensions. I
would also require a nonnegative integer range, or define signed formatting:
with the current %o, -1 is typically shown as 037777777777 on machines with
32-bit int. All three GUCs marked GUC_SHOW_IN_OCTAL by this patch already
have a minimum of zero.
I don't really feel a need to place such a restriction on the usage of
the flag. %o means unsigned display everywhere, per POSIX, so there's
not a portability argument for it.
Maybe the new regression test query against pg_settings could also include
setting and reset_val, as in the opening example. The former would exercise
the replacement of the old show hooks, while the latter is the only changed
auxiliary value that the test does not currently check.
Those omissions are intentional, because otherwise the test would fail
in "installcheck" mode on installations with non-default values for
these GUCs. We could avoid that gotcha if we could locally SET the
value to be displayed, but none of these GUCs permit session-level
settings. I didn't think it was worth going to the trouble of, say,
creating a TAP test just so we could exercise that.
With those small changes, the patch looks ready for committer.
What do you think of Rui's suggestion for a HINT if we're throwing
out-of-range for an octal GUC? I think it's a little more complicated
than he paints it, because the syntax rules are different in
postgresql.conf than in SQL, but we could make it happen if we thought
it was worth the trouble. In the initial draft, I felt that showing
the interpreted value in octal would be enough of a clue, but perhaps
that judgment is wrong.
regards, tom lane
In the initial draft, I felt that showing the interpreted value in
octal would be enough of a clue, but perhaps that judgment is wrong.
I think showing 01200 together with the valid range (0000 .. 0777) is
already enough of a clue. I would not add a HINT.
Best regards, Andrey Borodin.
Tom Lane <tgl@sss.pgh.pa.us> wrote:
What do you think of Rui's suggestion for a HINT if we're throwing
out-of-range for an octal GUC? I think it's a little more complicated
than he paints it, because the syntax rules are different in
postgresql.conf than in SQL, but we could make it happen if we thought
it was worth the trouble.
Having looked at what the hint would actually have to say, I'd drop it.
The hint I sketched ("quote it, e.g. '0640'") is only right for SQL.
Each way a value can arrive has its own rule:
postgresql.conf: 0640 is octal (parse_int() uses strtol with base 0),
640 fails with the 01200 message, and 0o640 is a
syntax error in the file
ALTER SYSTEM: 0640 is decimal 640 and fails with 01200;
'0640' and 0o640 are octal
postgres -c: 0640 is octal, 640 fails with 01200, and 0o640 is
rejected as an invalid value
And the error site cannot tell these apart: ALTER SYSTEM validates
through parse_and_validate_value() with PGC_S_FILE, the same source as
the file, and by then the value is the string "640" either way. A hint
that is correct everywhere would have to state both rules ("start with
a 0; in SQL also quote it or write 0o640"), which is longer than the
clue the octal echo already gives. I agree with Andrey that 01200 next
to (0000 .. 0777) is enough.
v1 still applies and builds cleanly on today's master (798bdcae89).
LGTM as is.
Regards,
Rui
Rui Zhao <zhaorui126@gmail.com> writes:
Tom Lane <tgl@sss.pgh.pa.us> wrote:
What do you think of Rui's suggestion for a HINT if we're throwing
out-of-range for an octal GUC? I think it's a little more complicated
than he paints it, because the syntax rules are different in
postgresql.conf than in SQL, but we could make it happen if we thought
it was worth the trouble.
Having looked at what the hint would actually have to say, I'd drop it.
Yeah, I suspected it'd be too complicated to be useful. Sounds like
we're all on the same page, so I'll get this pushed soon.
regards, tom lane