Re: initdb caching during tests
От | Andres Freund |
---|---|
Тема | Re: initdb caching during tests |
Дата | |
Msg-id | 20230824221000.y5owt6c2bddyuy6o@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: initdb caching during tests (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: initdb caching during tests
Re: initdb caching during tests Re: initdb caching during tests |
Список | pgsql-hackers |
Hi, On 2023-08-23 10:10:31 +0200, Daniel Gustafsson wrote: > > On 23 Aug 2023, at 03:17, Andres Freund <andres@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. Let's see what the buildfarm says - it's not inconceivable that it'll show some issues. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: