Re: Set arbitrary GUC options during initdb

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-03-22T18:33:09Z
Lists: pgsql-hackers
I wrote:
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>> I would remove the
>> #if DEF_PGPORT != 5432
>> This was in the previous code too, but now if we remove it, then we 
>> don't have any more hardcoded 5432 left, which seems like a nice 
>> improvement in cleanliness.

> Hm.  That'll waste a few cycles during initdb; not sure if the extra
> cleanliness is worth it.  It's not like that number is going to change.

After further thought I did it as you suggest.  I think the only case
where we really care about shaving milliseconds from initdb is in debug
builds (e.g. buildfarm), which very likely get built with nondefault
DEF_PGPORT anyway.

I did get a bee in my bonnet about how replace_token (and now
replace_guc_value) leak memory like there's no tomorrow.  The leakage
amounts to about a megabyte per run according to valgrind, and it's
not going anywhere but up as we add more calls of those functions.
So I made a quick change to redefine them in a less leak-prone way.

			regards, tom lane



Commits

  1. Fix initdb's handling of min_wal_size and max_wal_size.

  2. Reduce memory leakage in initdb.

  3. Add "-c name=value" switch to initdb.