Re: Why does bootstrap and later initdb stages happen via client? - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Why does bootstrap and later initdb stages happen via client?
Date
Msg-id a2c2004d-2316-4c35-047c-1a26e76ae113@dunslane.net
Whole thread Raw
Responses Re: Why does bootstrap and later initdb stages happen via client?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 9/8/21 3:07 PM, Andres Freund wrote:
> Hi,
>
> While hacking on AIO I wanted to build the windows portion from linux. That
> works surprisingly well with cross-building using --host=x86_64-w64-mingw32 .
>
> What didn't work as well was running things under wine. It turns out that the
> server itself works ok, but that initdb hangs because of a bug in wine ([1]),
> leading to the bootstrap process hanging while trying to read more input.
>
>
> Which made me wonder: What is really the point of doing so much setup as part
> of initdb? Of course a wine bug isn't a reason to change anything, but I see
> other reasons it might be worth thinking about moving more of initdb's logic
> into the backend.
>
> There of course is historical raisins for things happening in initdb - the
> setup logic didn't use to be C. But now that it is C, it seems a bit absurd to
> read bootstrap data in initdb, write the data to a pipe, and then read it
> again in the backend. It for sure doesn't make things faster.


I guess the downside would be that we'd need to teach the backend how to
do more stuff that only needs to be done once per cluster, and then that
code would be dead space for the rest of the lifetime of the cluster.


Maybe the difference is sufficiently small that it doesn't matter.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: refactoring basebackup.c
Next
From: Magnus Hagander
Date:
Subject: Re: unnesting multirange data types