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
-
Fix initdb's handling of min_wal_size and max_wal_size.
- b48af6d174bb 16.0 landed
-
Reduce memory leakage in initdb.
- 4fe2aa7656dc 16.0 landed
-
Add "-c name=value" switch to initdb.
- 3e51b278db6a 16.0 landed