Re: A configure.in patch check (fwd)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: A configure.in patch check (fwd)
Date: 2002-08-25 16:43:11
Message-ID: 19396.1030293791@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)uk> writes:
> It is a GUC. It's exactly like max_backends. I took the easy route out and
> just followed where DEF_MAXBACKENDS was being set rather than hard wiring
> the value any where.

Oh. Well, skip the configure part: the only reason there's still a
configure parameter for maxbackends is backwards compatibility with
ancient configure scripts (from days when it was in fact frozen at
configure time). I don't see a need to provide one for reserved_slots.

> Rather distressingly in order to get this new value into where it's needed
> I had to hit quite a few files, more than I would have expected. Again I
> just followed how MaxBackends was being sent to where it was needed but is
> there any particular reason why storage/ipc/sinvaladt.c:SIBackendInit()
> can't access MaxBackends and my new ReservedBackends directly?

Probably not. Again, the way that MaxBackends is handled is largely
legacy code. You'd have been better off looking at almost any other
GUC parameter as a template ;-)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-08-25 16:55:54 Re: Documentation of maximum input string lengths
Previous Message Nigel J. Andrews 2002-08-25 16:09:04 Re: A configure.in patch check (fwd)