Improving display of octal GUCs

Started by Tom Lane25 days ago5 messageshackers
Jump to latest
#1Tom Lane
tgl@sss.pgh.pa.us

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

[1]: /messages/by-id/19540-e641040b089ab768@postgresql.org

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
#2Fabrízio de Royes Mello
fabriziomello@gmail.com
In reply to: Tom Lane (#1)
Re: Improving display of octal GUCs

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

#3Tatsuya Kawata
kawatatatsuya0913@gmail.com
In reply to: Fabrízio de Royes Mello (#2)
Re: Improving display of octal GUCs

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

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Tatsuya Kawata (#3)
Re: Improving display of octal GUCs

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

#5Rui Zhao
zhaorui126@gmail.com
In reply to: Tom Lane (#4)
Re: Improving display of octal GUCs

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