On Saturday, January 6, 2024, Bruce Momjian <br...@momjian.us> wrote:
> On Sat, Jan 6, 2024 at 08:11:14PM -0700, David G. Johnston wrote: > > On Saturday, January 6, 2024, Bruce Momjian <br...@momjian.us> wrote: > > > > This commit: > > > > commit 910cab820d > > Author: Alvaro Herrera <alvhe...@alvh.no-ip.org> > > Date: Fri Nov 18 11:59:26 2022 +0100 > > > > Add glossary entries related to superusers > > > > Extracted from a more ambitious patch. > > > > Author: David G. Johnston <david.g.johns...@gmail.com> > > Discussion: https://postgr.es/m/ > CAKFQuwZC4K0XYBm0bwBMDOZySBqhO > > sekdhluaw4vpi+ozi8...@mail.gmail.com > > > > used this text for the --username option: > > > > -U username > > --username=username > > Selects the user name of the bootstrap superuser. This > defaults > > to the name of the cluster owner. > > > > This seems wrong since the cluster owner doesn't exist until the > cluster > > is created. The text exists in PG 16 and master. The attached patch > > fixes this. > > > > > > The glossary defines cluster owner as the pre-existing operating system > user. > > No, it does not. > > > There may be an argument that installation user is a better term but the > > existing choice isn’t wrong. If you are going to change it you need to > update > > the glossary as well. The description in initdb uses cluster owner as > well. > > > > I agree we presently use a mix of set and specify in these definitions > so the > > word choice of selects is out-of-place. > > The patch says: > > + <glossentry id="glossary-cluster-owner"> > + <glossterm>Cluster owner</glossterm> > + <glossdef> > + <para> > --> + The operating system user that owns the > --> + <glossterm linkend="glossary-data-directory">data > directory</glossterm> > + and under which the <literal>postgres</literal> process is > run. > + It is required that this user exist prior to creating a new > + <glossterm linkend="glossary-db-cluster">database > cluster</glossterm>. > + </para> > + <para> > + On operating systems with a <literal>root</literal> user, > + said user is not allowed to be the cluster owner. > + </para> > + </glossdef> > + </glossentry> > > How can you default to be the owner of something that doesn't exist before > it is created? > > Also, the initdb code gets the default username from geteuid(), the > effective process owner; man geteuid says: > > geteuid() returns the effective user ID of the calling process. > > so it is not the owner of the data dirctory, but the installation user. > > I am open to saying that it is the owner of the data directory but we > would then need to change initdb to do that, and we aren't going to > backpatch that. > Ok, I see your point. Given that the installation users becomes the cluster owner by virtue of doing the only job they have, running initdb, defining both seemed excessive but it is indeed more precise. I would probably avoid install user though because of the probable confusion with the user that installed the distribution package as opposed to the one initializing the cluster (we don’t call it installing a cluster). So maybe a new defined term “cluster initializer”? David J.
