Re: Why does bootstrap and later initdb stages happen via client?

On 9/8/21 5:48 PM, Andres Freund wrote:
> Hi,
>
> On September 8, 2021 1:24:00 PM PDT, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> On 9/8/21 3:07 PM, Andres Freund wrote:
>>> 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.
> Unused code doesn't itself cost much - the OS won't even page it in. And disk space wise, there's not much difference between code in initdb and code in postgres. It's callsites to the code that can be problematic. But there were already paying the price via --boot and a fair number of if (bootstrap) blocks.
>

Fair enough. You're quite right, of course, the original design of
initdb.c was to do what the preceding shell script did as closely as
possible. It does leak a bit of memory, which doesn't matter in the
context of a short-lived program - but that shouldn't be too hard to
manage in the backend.

cheers

andrew

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