From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Set arbitrary GUC options during initdb |
Date: | 2023-03-22 18:33:09 |
Message-ID: | 1644803.1679509989@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-03-22 18:42:26 | Re: Request for comment on setting binary format output per session |
Previous Message | Melanie Plageman | 2023-03-22 18:21:12 | Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry |