Re: Set arbitrary GUC options during initdb

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

In response to

Responses

Browse pgsql-hackers by date

  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