Re: initdb / bootstrap design - Mailing list pgsql-hackers

From Tom Lane
Subject Re: initdb / bootstrap design
Date
Msg-id 3391407.1645035881@sss.pgh.pa.us
Whole thread Raw
In response to initdb / bootstrap design  (Andres Freund <andres@anarazel.de>)
Responses Re: initdb / bootstrap design  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> Sure, there's a few tokens that we replace in initdb. As it turns out there'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 encoding,
> 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: do only critical work during single-user vacuum?
Next
From: Peter Geoghegan
Date:
Subject: Re: do only critical work during single-user vacuum?