Re: Set arbitrary GUC options during initdb - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Set arbitrary GUC options during initdb
Date
Msg-id 1644803.1679509989@sss.pgh.pa.us
Whole thread Raw
In response to Re: Set arbitrary GUC options during initdb  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Set arbitrary GUC options during initdb  (Andres Freund <andres@anarazel.de>)
List 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



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Next
From: Tom Lane
Date:
Subject: Re: Request for comment on setting binary format output per session