From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Why does bootstrap and later initdb stages happen via client? |
Date: | 2021-09-08 20:24:00 |
Message-ID: | a2c2004d-2316-4c35-047c-1a26e76ae113@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2021-09-08 20:30:04 | Re: unnesting multirange data types |
Previous Message | Robert Haas | 2021-09-08 19:39:42 | Re: refactoring basebackup.c |