Postgres Pro
Downloads
Home   >   mailing lists

Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all" - Mailing list pgsql-general

From David G. Johnston
Subject Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"
Date
Msg-id CAKFQuwZprhncFbscQ+uNSYBcWHg=2buQRF4YO1Lp=R8nSRiacQ@mail.gmail.com
Whole thread Raw
In response to Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"  (Bryn Llewellyn <bryn@yugabyte.com>)
List pgsql-general
Tree view
On Wed, Nov 2, 2022 at 6:22 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
Some repetition of what Adrian just posted ahead...

On Wed, Nov 2, 2022 at 3:31 PM Bryn Llewellyn <bryn@yugabyte.com> wrote:

How can it be that the PG doc itself leads you by the hand to a regime where you need to use undocumented features?

The documentation tries to make clear that if you use third-party packaging to install PostgreSQL (which most people should) that the documentation for the packaging should describe this layer where PostgreSQL and the operating system intersect.  You even quoted it: "follow the instructions for the specific platform.", though reading that now I think something along the lines of:

 "Additionally, while reading the next chapter, Server Setup and Operation, is recommended if you are using a binary package the setup and operational environment it creates is likely to be somewhat different than what is described in this documentation.  Please read the documentation for the packages you install to learn how it behaves and what additional platform-specific features it provides."


Actually, not sure on the best approach here, since the Server Setup chapter already says:

https://www.postgresql.org/docs/current/runtime.html

"The directions in this chapter assume that you are working with plain PostgreSQL without any additional infrastructure, for example a copy that you built from source according to the directions in the preceding chapters. If you are working with a pre-packaged or vendor-supplied version of PostgreSQL, it is likely that the packager has made special provisions for installing and starting the database server according to your system's conventions. Consult the package-level documentation for details."

However, that appears below-the-fold after a decent sized table of contents.

Changing anything now feels like an over-reaction to a single incident, but I sympathize with the general confusion all this causes, and the fact it is only in the recent past that we've made this first attempt to rectify the situation by adding these comments.  A second-pass based upon this encounter seems at least reasonable.  Whether I or others end up deciding it is worth proposing a patch remains to be seen.

David J.

pgsql-general by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"
Next
From: Rob Sargent
Date:
Subject: Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"