> david.g.johnston@xxxxxxxxx wrote: > > Some repetition of what Adrian just posted ahead... > >> bryn@xxxxxxxxxxxx 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. Thanks for your explanations, David. I believe that my point about how all this seems to me is well taken. I might concede that the Debian/Ubuntu packaging provides adequate reference doc by implementing its "man" pages. But I haven't found anything like a user guide that explains *why* ordinarily documented PG features have been hidden from sight (but not removed) and how (if the Debian/Ubuntu alternatives are just wrappers for the native PG) one might do that wrapping by hand. 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 separate VMs 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've referred 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 it to 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've sketched. I'm looking forward to returning to that project and putting all that we've been discussing here behind me.
