> david.g.johns...@gmail.com wrote: > > Some repetition of what Adrian just posted ahead... > >> b...@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.
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.
