Improving display of octal GUCs
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
Attachments:
v1-0001-Improve-display-of-GUCs-that-are-customarily-writ.patchtext/x-diff; charset=us-ascii; name*0=v1-0001-Improve-display-of-GUCs-that-are-customarily-writ.p; name*1=atchDownload+82-65
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