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 1weYQz-004rlj-1J for pgsql-bugs@arkaria.postgresql.org; Tue, 30 Jun 2026 13:23:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1weYQy-008IH2-1C for pgsql-bugs@arkaria.postgresql.org; Tue, 30 Jun 2026 13:23:28 +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 1weSEQ-006qyx-2P for pgsql-bugs@lists.postgresql.org; Tue, 30 Jun 2026 06:46:06 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1weSEP-00000000sVO-1DLj for pgsql-bugs@lists.postgresql.org; Tue, 30 Jun 2026 06:46:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=PUHlHd78B5QiNpV0pSpNYP+UhkbtUvKlEY8Fw8lxEEY=; b=v7DyEllNVrT6WiD16c0fvlzz54 2S7zVf7yBrmmBjX0mesCC+3LCkz7SOytKZ0v8tmdNqllF/lFC7MvUUAXMpq9wHk2sfzAfOIQCdB9Y 7l+vniHa60G7HgL8jhoEACGFDWQYl/4x1YN/d+dx3hutxCNJmZy7pmX7d/FWCrw4hlmvJIOz5j+4e i0Mp9x3rqNrzHgAIkO/5MOOCO1r4ryx7uz3mVz92kpCb/udf4gHDEQPX7YqPeIOWBaG9xu5CHu/qN wngt4emuf7Mxr8p6uHtsLxh4uASW8VUSQ85IrSi98q3+fO0jKllhAZ3ZULCB/x8iggg27IuC7/wCD 2UKRjq5A==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1weSEP-008cRb-07 for pgsql-bugs@lists.postgresql.org; Tue, 30 Jun 2026 06:46:05 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1weSEN-006YWi-20 for pgsql-bugs@lists.postgresql.org; Tue, 30 Jun 2026 06:46:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19540: Inconsistent integer-to-octal formatting for permission GUCs in pg_settings (boot_val vs setting) To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: jobinau@gmail.com Reply-To: jobinau@gmail.com, pgsql-bugs@lists.postgresql.org Date: Tue, 30 Jun 2026 06:45:35 +0000 Message-ID: <19540-e641040b089ab768@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following bug has been logged on the website: Bug reference: 19540 Logged by: Jobin Augustine Email address: jobinau@gmail.com PostgreSQL version: 18.4 Operating system: All Description: =20 This is more of an undocumented behavior in all PostgreSQL versions. Steps to reproduce: postgres=3D# SELECT name, setting, boot_val FROM pg_settings WHERE name IN ('data_directory_mode', 'log_file_mode', 'unix_socket_permissions'); Actual Result : name | setting | boot_val -------------------------+---------+---------- data_directory_mode | 0700 | 448 log_file_mode | 0600 | 384 unix_socket_permissions | 0777 | 511 (3 rows) File/Directory permissions like 448,384 and 511 may not make a good sense for a user. Either a decoded value or mentioning it in docs would be great. Displaying the value consistent with "setting" column is most desirable from a user perspective. Thank you, Jobin.