Re: Documentation for initdb option --waldir

at it might help to know > that initdb will create a symbolic link from data/pg_wal to the custom > directory with the option --waldir. > > Thank you for the observation. This indeed seems like something we should cover in a bit more detail. How does the proposed patch (attached) loo

Re: Documentation for initdb option --waldir

On Saturday, March 29, 2025, Robert Treat wrote: > On Thu, Mar 27, 2025 at 5:57 PM David G. Johnston > wrote: > > On Thu, Mar 27, 2025 at 2:28 PM Robert Treat wrote: > >> On Thu, Mar 27, 2025 at 12:06 PM David G. Johnston > >> wrote: > >> > I expanded upon the material regarding using differen

Re: Documentation for initdb option --waldir

On Sat, 2025-03-29 at 10:26 -0400, Robert Treat wrote: > "Best practice is to create a directory within the mount-point > directory that is owned by the PostgreSQL user, and then create the > data directory within that. This avoids permissions problems,..." > > Which I do remember having tried to

Re: Documentation for initdb option --waldir

On Saturday, March 29, 2025, Gurjeet Singh wrote: > On Sat Mar 29, 2025 at 9:26 AM PDT, Laurenz Albe wrote: > > > On the other hand, PostgreSQL will protest if the directory isn't > > empty... > > Specifically, initdb will complain if the directory it's t

Re: Documentation for initdb option --waldir

On Sat Mar 29, 2025 at 9:26 AM PDT, Laurenz Albe wrote: > On the other hand, PostgreSQL will protest if the directory isn't > empty... Specifically, initdb will complain if the directory it's trying to initialize is not empty. Best regards, Gurjeet http://Gurje.et

Re: Documentation for initdb option --waldir

9%40sss.pgh.pa.us A couple of reasons for [not placing data diretory at a mount point] are: 1. Mount-point directories should be owned by root, never by an unprivileged account such as postgres. IIRC there are good security reasons for this practice, though I don't recall all the details

Re: Documentation for initdb option --waldir

On Sat, Mar 29, 2025 at 10:58 AM David G. Johnston wrote: > > On Saturday, March 29, 2025, Robert Treat wrote: >> >> On Thu, Mar 27, 2025 at 5:57 PM David G. Johnston >> wrote: >> > On Thu, Mar 27, 2025 at 2:28 PM Robert Treat wrote: >> >> On Thu, Mar 27, 2025 at 12:06 PM David G. Johnston >> >

Re: Documentation for initdb option --waldir

On Thu, Mar 27, 2025 at 5:57 PM David G. Johnston wrote: > On Thu, Mar 27, 2025 at 2:28 PM Robert Treat wrote: >> On Thu, Mar 27, 2025 at 12:06 PM David G. Johnston >> wrote: >> > I expanded upon the material regarding using different file systems and >> > disks. >> > >> > I would like to add a

Re: Documentation for initdb option --waldir

On Thu, Mar 27, 2025 at 2:28 PM Robert Treat wrote: > On Thu, Mar 27, 2025 at 12:06 PM David G. Johnston > wrote: > > > > Version 2 Attached > > > > -This option specifies the directory where the write-ahead log > > -should be stored. > > +This option specifies the direct

Re: Documentation for initdb option --waldir

On Thu, Mar 27, 2025 at 12:06 PM David G. Johnston wrote: > > Version 2 Attached > > -This option specifies the directory where the write-ahead log > -should be stored. > +This option specifies the directory in which to store write-ahead > log files. > +See for mo

Re: Documentation for initdb option --waldir

e directory must be empty. @@ -668,6 +670,7 @@ PostgreSQL documentation initdb can also be invoked via pg_ctl initdb. + diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml index 9659f76042..2871ae9320 100644 --- a/doc/src/sgml/ref/pg_base

Re: Documentation for initdb option --waldir

On Thu, Mar 27, 2025, at 8:40 AM, Theodor Herlo wrote: > Both look great to me! I thought the advantage of having different devices > is also to easy I/O load. But I guess you have to decide for yourself what is > the best strategy. For me it was important to know what initdb

AW: Documentation for initdb option --waldir

Both look great to me! I thought the advantage of having different devices is also to easy I/O load. But I guess you have to decide for yourself what is the best strategy. For me it was important to know what initdb does with ---waldir. And this is nicely explained here. One more little thing

Re: Documentation for initdb option --waldir

On Wed, 2025-03-26 at 17:34 -0700, David G. Johnston wrote: > + > + The pg_wal subdirectory will always exist within the > + data directory. This is where PostgreSQL > + sends its write-ahead log (WAL) files. > + Specifying the --waldir option turns this subdirectory > entry > + into

Documentation for initdb option --waldir

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/17/app-initdb.html Description: Hi all, During troubleshooting with a customer we found that it might help to know that initdb will create a symbolic link from data/pg_wal to the custom

Re: initdb username doc bug

On Wed, Jan 10, 2024 at 06:05:17PM +0100, Álvaro Herrera wrote: > On 2024-Jan-10, Bruce Momjian wrote: > > > On Mon, Jan 8, 2024 at 04:50:19PM -0500, Tom Lane wrote: > > > Bruce Momjian writes: > > > > Agreed, updated patch attached. > > > > > > WFM. > > > > Patch applied back to PG 16, which

Re: initdb username doc bug

On 2024-Jan-10, Bruce Momjian wrote: > On Mon, Jan 8, 2024 at 04:50:19PM -0500, Tom Lane wrote: > > Bruce Momjian writes: > > > Agreed, updated patch attached. > > > > WFM. > > Patch applied back to PG 16, which is where the erroneous text was > added. Thank you! It looks good to me too. So

Re: initdb username doc bug

On Mon, Jan 8, 2024 at 04:50:19PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > Agreed, updated patch attached. > > WFM. Patch applied back to PG 16, which is where the erroneous text was added. -- Bruce Momjian https://momjian.us EDB htt

Re: initdb username doc bug

Bruce Momjian writes: > Agreed, updated patch attached. WFM. regards, tom lane

Re: initdb username doc bug

On Mon, Jan 8, 2024 at 2:26 PM Bruce Momjian wrote: > On Sat, Jan 6, 2024 at 11:27:14PM -0500, Tom Lane wrote: > > "David G. Johnston" writes: > > > Or just the bit more verbose “user running the initdb command” and > don’t > > > bother giving it a lab

Re: initdb username doc bug

On Sat, Jan 6, 2024 at 11:27:14PM -0500, Tom Lane wrote: > "David G. Johnston" writes: > > Or just the bit more verbose “user running the initdb command” and don’t > > bother giving it a label, which is basically the approach used in the > > description for initd

Re: initdb username doc bug

"David G. Johnston" writes: > Or just the bit more verbose “user running the initdb command” and don’t > bother giving it a label, which is basically the approach used in the > description for initdb anyway. Or if you want a few more words, "name of the operating-system

Re: initdb username doc bug

ser. >> >> 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. >> > > So maybe a new defined term “cluster initializer”? > Or just the bit more ve

Re: initdb username doc bug

n 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 >

Re: initdb username doc bug

ay 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 m

Re: initdb username doc bug

ch > fixes this. > The glossary defines cluster owner as the pre-existing operating system user. 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

initdb username doc bug

This commit: commit 910cab820d Author: Alvaro Herrera 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

Re: initdb: nothing about template0

PG Doc comments form writes: > Is it correct that this page does not contain information about the > template0 database. > The same goes for the "Create Database Cluster" page > (https://www.postgresql.org/docs/14/creating-cluster.html). Yeah, this text evidently wasn't updated when we invented t

initdb: nothing about template0

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/app-initdb.html Description: Is it correct that this page does not contain information about the template0 database. The same goes for the "Create Database Cluster" page (https://www.postg

Re: initdb - creating clusters

Daniel Gustafsson writes: >> On 2 Sep 2020, at 18:43, Tom Lane wrote: >> I took a stab at doing it that way, as attached. (I couldn't resist >> the temptation to do some minor editing on adjacent material, too.) > LGTM. I didn't try to build the docs with this applied, but reading it I > can'

Re: initdb - creating clusters

> On 2 Sep 2020, at 18:43, Tom Lane wrote: > I took a stab at doing it that way, as attached. (I couldn't resist > the temptation to do some minor editing on adjacent material, too.) LGTM. I didn't try to build the docs with this applied, but reading it I can't see anything odd about the marku

Re: initdb - creating clusters

installation. @@ -71,11 +89,26 @@ completely up to you where you choose to store your data. There is no default, although locations such as /usr/local/pgsql/data or - /var/lib/pgsql/data are popular. To initialize a - database cluster, use the command ,initdb which is -

Re: initdb - creating clusters

> On 30 Aug 2020, at 17:21, Tom Lane wrote: > > Thomas Munro writes: >> + The discussions in this chapter assume that you are working with >> + an unmodified version of PostgreSQL, >> + for example one that you built from source according to the directions >> + in the preceding chapters. If

Re: initdb - creating clusters

On 30.08.20 17:21, Tom Lane wrote: Do you have a feeling one way or the other about whether to repeat some of this text in each of the relevant sub-sections? I initially didn't want to do that, but thinking about how people consume the HTML docs, I'm afraid that anything not appearing on the sam

Re: initdb - creating clusters

Thomas Munro writes: > + The discussions in this chapter assume that you are working with > + an unmodified version of PostgreSQL, > + for example one that you built from source according to the directions > + in the preceding chapters. If you are working with a pre-packaged > Rather than "u

Re: initdb - creating clusters

ng any service when you install it, implying that it must also run initdb for you).

Re: initdb - creating clusters

> On 22 Jul 2020, at 18:34, Bruce Momjian wrote: > > On Tue, Jul 21, 2020 at 10:40:59AM +0200, Daniel Gustafsson wrote: >>> On 21 Jul 2020, at 02:25, Bruce Momjian wrote: >>> >>> On Thu, Jul 9, 2020 at 03:25:14PM +, PG Doc comments form wrote: looking. For instance the documentation

Re: initdb - creating clusters

On Tue, Jul 21, 2020 at 10:40:59AM +0200, Daniel Gustafsson wrote: > > On 21 Jul 2020, at 02:25, Bruce Momjian wrote: > > > > On Thu, Jul 9, 2020 at 03:25:14PM +, PG Doc comments form wrote: > >> looking. For instance the documentation on replication strategies includes > >> proprietary sol

Re: initdb - creating clusters

> On 21 Jul 2020, at 02:25, Bruce Momjian wrote: > > On Thu, Jul 9, 2020 at 03:25:14PM +, PG Doc comments form wrote: >> looking. For instance the documentation on replication strategies includes >> proprietary solutions. > > Uh, what proprietary solutions are listed in our documentation?

Re: initdb - creating clusters

On Thu, Jul 9, 2020 at 03:25:14PM +, PG Doc comments form wrote: > looking. For instance the documentation on replication strategies includes > proprietary solutions. Uh, what proprietary solutions are listed in our documentation? -- Bruce Momjian https://momjian.us Enterprise

Re: initdb - creating clusters

> On 12 Jul 2020, at 00:24, Tom Lane wrote: > > Daniel Gustafsson writes: >>> On 11 Jul 2020, at 23:36, Tom Lane wrote: >>> + For example, there may be special scripts for creating a database >>> + cluster. There almost certainly will be a mechanism for starting >>> + the server, > >> Aren

Re: initdb - creating clusters

On Sat, Jul 11, 2020 at 2:37 PM Tom Lane wrote: > Another approach would be to put something along this line at the heads > of each of the relevant sections, which'd be 18.1, 18.2, 18.3, 18.5, > and 18.6 by my count. That seems very repetitive; but it would have > the advantage that people could

Re: initdb - creating clusters

Daniel Gustafsson writes: >> On 11 Jul 2020, at 23:36, Tom Lane wrote: >> + For example, there may be special scripts for creating a database >> + cluster. There almost certainly will be a mechanism for starting >> + the server, > Aren't we really talking about "running the server as a servi

Re: initdb - creating clusters

> On 11 Jul 2020, at 23:36, Tom Lane wrote: > + For example, there may be special scripts for creating a database > + cluster. There almost certainly will be a mechanism for starting > + the server, Aren't we really talking about "running the server as a service" and not just starting it? P

Re: initdb - creating clusters

attached? I think the problem is more general than that. The packager might well provide a substitute or wrapper for initdb, but it's even more likely that there's some other way to start and stop the server than what we describe. I experimented with putting a disclaimer at th

Re: initdb - creating clusters

On Thu, 2020-07-09 at 15:25 +, PG Doc comments form wrote: > I'm searching for what a cluster is and how to create one. The > documentation tells me to use initdb -D path/to/cluster. I am told that > this is installed when I installed postgresql. I try to run it wit

initdb - creating clusters

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/10/creating-cluster.html Description: I'm searching for what a cluster is and how to create one. The documentation tells me to use initdb -D path/to/cluster. I am told that th

Re: References between initdb and pg_controldata

On Sat, Jan 4, 2020 at 10:10:08AM +, Paul Weiss wrote: > As with other see-alsos in Part VI, I think it would be useful to have > see-alsos between initdb and pg_controldata. Currently the pg_controldata page > at least mentions initdb, but the initdb page does not mention pg_control

References between initdb and pg_controldata

As with other see-alsos in Part VI, I think it would be useful to have see-alsos between initdb and pg_controldata. Currently the pg_controldata page at least mentions initdb, but the initdb page does not mention pg_controldata. Paul

Re: It is recommended to add detailed description about initdb ...

On Fri, Dec 6, 2019 at 09:22:01AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/creating-cluster.html > Description: > > When I run initdb -D /home/myname/pgsql/data in /hom

It is recommended to add detailed description about initdb ...

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/creating-cluster.html Description: When I run initdb -D /home/myname/pgsql/data in /home/myname/pgsql/bin, it return bash: initdb: command not found The others are like this. It must

First WAL segment file that initdb creates

Hi, There is the following description in wal.sgml. Segment files are given ever-increasing numbers as names, starting at 0001. But the first WAL segment file that initdb creates is 00010001 not 0001. This change was caused by

Re: initdb recommendations

On 4/8/19 8:44 AM, Magnus Hagander wrote: > On Mon, Apr 8, 2019 at 2:41 PM Jonathan S. Katz > wrote: > > On 4/8/19 8:25 AM, Peter Eisentraut wrote: > > On 2019-04-05 18:11, Jonathan S. Katz wrote: > >> +    > >> +      We recommend using the -W, >

Re: initdb recommendations

On Mon, Apr 8, 2019 at 2:41 PM Jonathan S. Katz wrote: > On 4/8/19 8:25 AM, Peter Eisentraut wrote: > > On 2019-04-05 18:11, Jonathan S. Katz wrote: > >> + > >> + We recommend using the -W, > --pwprompt, > >> + or --pwfile flags to assign a password to the > database > >> + sup

Re: initdb recommendations

On 4/8/19 8:25 AM, Peter Eisentraut wrote: > On 2019-04-05 18:11, Jonathan S. Katz wrote: >> + >> + We recommend using the -W, >> --pwprompt, >> + or --pwfile flags to assign a password to the >> database >> + superuser, and to override the pg_hba.conf >> default >> + gen

Re: initdb recommendations

On 2019-04-05 18:11, Jonathan S. Katz wrote: > + > + We recommend using the -W, > --pwprompt, > + or --pwfile flags to assign a password to the database > + superuser, and to override the pg_hba.conf default > + generation using -auth-local peer for local > connections, >

Re: initdb recommendations

hange the default behavior for initdb, but I would suggest that a safe > > > starting point would be to ensure we call this out) > > > > I think we should just change the defaults. There is a risk of warning > > fatigue. initdb does warn about this, so anyone who cared

Re: initdb recommendations

On Fri, Apr 5, 2019 at 10:58 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-04-05 18:11, Jonathan S. Katz wrote: > > (There could be an additional discussion about whether or not we want to > > change the default behavior for initdb, but I woul

Re: initdb recommendations

On 4/5/19 4:58 PM, Peter Eisentraut wrote: > On 2019-04-05 18:11, Jonathan S. Katz wrote: >> (There could be an additional discussion about whether or not we want to >> change the default behavior for initdb, but I would suggest that a safe >> starting point would be to en

Re: initdb recommendations

On 2019-04-05 18:11, Jonathan S. Katz wrote: > (There could be an additional discussion about whether or not we want to > change the default behavior for initdb, but I would suggest that a safe > starting point would be to ensure we call this out) I think we should just change the

initdb recommendations

Given some of the recent hubbub and analysis of CVE entries, one part of the documentation[1] that could be further clarified is what initdb does by default, i.e. creates a cluster where users can connect with trust authentication. While this may be great for people who are hacking or running

Re: initdb

Hi Tom, I was running initdb command when calling the postgresql96-setup command. Trying to run this as the user postgres failed. /usr/pgsql-9.6/bin/postgresql96-setup initdb The database was created under /var/lib/pgsql/9.6/data thanks Scott. On Mon, Jan 15, 2018 at 4:56 PM, Tom Lane

Re: initdb

=?utf-8?q?PG_Doc_comments_form?= writes: > So I was trying to create a new db with initdb. I tried to run this with > the postgres user after installing the server rpm and it failed with runuser > may not be run as non-root users. So then for fun I tried to run init db > as the roo

initdb

The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.6/static/app-initdb.html Description: So I was trying to create a new db with initdb. I tried to run this with the postgres user after installing the server rpm and it failed with runuser