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@gmail.com wrote:
>
> Some repetition of what Adrian just posted ahead...
>
>> 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
somethingalong the lines of: 
>
>  "Additionally, while reading the next chapter, Server Setup and Operation, is recommended if you are using a binary
packagethe setup and operational environment it creates is likely to be somewhat different than what is described in
thisdocumentation.  Please read the documentation for the packages you install to learn how it behaves and what
additionalplatform-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
youare working with a pre-packaged or vendor-supplied version of PostgreSQL, it is likely that the packager has made
specialprovisions for installing and starting the database server according to your system's conventions. Consult the
package-leveldocumentation 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
allthis causes, and the fact it is only in the recent past that we've made this first attempt to rectify the situation
byadding these comments.  A second-pass based upon this encounter seems at least reasonable.  Whether I or others end
updeciding it is worth proposing a patch remains to be seen. 

Thanks for your explanations, David. I believe that my point about how all this seems to me is well taken. I might
concedethat the Debian/Ubuntu packaging provides adequate reference doc by implementing its "man" pages. But I haven't
foundanything like a user guide that explains *why* ordinarily documented PG features have been hidden from sight (but
notremoved) and how (if the Debian/Ubuntu alternatives are just wrappers for the native PG) one might do that wrapping
byhand. Doing this would demonstrate what benefits the wrapping brings. 

Anyway, I now have a working PG system and useful notes. When, presently, I make a second VM for PG 15 (I prefer
separateVMs over having both versions in the same VM) it should all go quickly and smoothly. 

I have no reason to describe to anybody else how to install and configure PG—and I certainly won't do this.

My interest in being able to re-establish the pristine cluster starting state reliably and quickly is to support my own
productivity.I'll presently have SQL scripts that establish the "multitenancy by self-imposed discipline" scheme that
I'vereferred to from any arbitrary state of population of a cluster. I don't intend my scheme to co-exist with other
schemes.And I don't expect there to be any real use cases for starting with an arbitrarily populated cluster and taking
itto a state that conforms with my scheme. Rather, all this is about demonstrating how to establish the scheme on the
assumption(but not requirement) that one starts with a brand-new cluster that will be dedicated to the approach that
I'vesketched. 

I'm looking forward to returning to that project and putting all that we've been discussing here behind me.