Hi,
On 2022-02-15 11:33:26 -0500, Tom Lane wrote:
> It might be worth trying to knock that down a bit, but I wouldn't
> start with a one-time leak of 28 bytes. It looks like the biggest
> offender is that we don't bother trying to reclaim the lines
> malloc'd by readfile() and replace_token(). Fixing that is *maybe*
> worth the trouble, but TBH no one has complained about initdb's
> memory consumption.
This reminds me: I recently noticed that the replace_token() stuff is a good
portion of the userspace time on windows. IIRC in debug builds only, I assume
because of some slow checking in the debug C runtime. It doesn't matter too
much overall, because the really expensive bit is the filesystem operations
being very slow (*).
It's a bit insane that we allocate the lines[] quite so many times, when
processing the same file. ~12k lines in postgres.bki * 8 replace_token() in
bootstrap_template1() starts to add up. The replacement patterns either are
compile time constants which we just should handle in genbki.pl, or have
exactly 1 replacement....
Greetings,
Andres Freund
*it looks like ntfs does *synchronous* journalling on every metadata
operation, which seems odd for an extremely widely used filesystem in
2022. But what do I know.
