On Fri, 25 Aug 2023 at 00:16, Andres Freund <and...@anarazel.de> wrote:
>
> Hi,
>
> On 2023-08-23 10:10:31 +0200, Daniel Gustafsson wrote:
> > > On 23 Aug 2023, at 03:17, Andres Freund <and...@anarazel.de> wrote:
> > > On 2023-08-22 23:47:24 +0200, Daniel Gustafsson wrote:
> >
> > >> My only small gripe is that I keep thinking about template databases for
> > >> CREATE
> > >> DATABASE when reading the error messages in this patch, which is clearly
> > >> not
> > >> related to what this does.
> > >>
> > >> + note("initializing database system by copying initdb template");
> > >>
> > >> I personally would've used cache instead of template in the user facing
> > >> parts
> > >> to keep concepts separated, but thats personal taste.
> > >
> > > I am going back and forth on that one (as one can notice with $subject).
> > > It
> > > doesn't quite seem like a cache, as it's not "created" on demand and only
> > > usable when the exactly same parameters are used repeatedly. But template
> > > is
> > > overloaded as you say...
> >
> > That's a fair point, cache is not a good word to describe a stored copy of
> > something prefabricated. Let's go with template, we can always refine
> > in-tree
> > if a better wording comes along.
>
> Cool. Pushed that way. Only change I made is to redirect the output of cp
> (and/or robocopy) in pg_regress, similar to how that was done for initdb
> proper.While working on some things that are prone to breaking initdb, I noticed that this template isn't generated with --no-clean, while pg_regress does do that. This meant `make check` didn't have any meaningful debuggable output when I broke the processes in initdb, which is undesirable. Attached a patch that fixes this for both make and meson, by adding --no-clean to the initdb template. Kind regards, Matthias van de Meent Neon (https://neon.tech)
v1-0001-Don-t-remove-initdb-template-when-initdb-fails.patch
Description: Binary data
