From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@postgresql.org
Subject: Re: initdb / bootstrap design
In-reply-to: <20220216021219.ygzrtb3hd5bn7olz@alap3.anarazel.de>
References: <20220216021219.ygzrtb3hd5bn7olz@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 15 Feb 2022 18:12:19 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3391406.1645035881.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Feb 2022 13:24:41 -0500
Message-ID: <3391407.1645035881@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3391407.1645035881%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> Sure, there's a few tokens that we replace in initdb. As it turns out th=
ere's
> only two rows that are actually variable. The username of the initial
> superuser in pg_authid and the pg_database row for template 1, where enc=
oding,
> lc_collate and lc_ctype varies. The rest is all compile time constant
> replacements we could do as part of genbki.pl.

I remembered the reason why it's done that way: if we replaced those
values during genbki.pl, the contents of postgres.bki would become
architecture-dependent, belying its distribution as a "share" file.
While we don't absolutely have to continue treating postgres.bki
as architecture-independent, I'm skeptical that there's enough win
here to justify a packaging change.

initdb is already plenty fast enough for any plausible production
usage; it's cases like check-world where we wish it were faster.
So I'm thinking what we really ought to pursue is the idea that's
been kicked around more than once of capturing the post-initdb
state of a cluster's files and just doing "cp -a" to duplicate that
later in the test run.

			regards, tom lane