Re: Set arbitrary GUC options during initdb
От | Tom Lane |
---|---|
Тема | Re: Set arbitrary GUC options during initdb |
Дата | |
Msg-id | 1644803.1679509989@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Set arbitrary GUC options during initdb (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Set arbitrary GUC options during initdb
|
Список | 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 по дате отправления: