A configure.in patch check (fwd)
Helps if I attach the patch...
---------- Forwarded message ----------
Date: Sun, 25 Aug 2002 14:36:19 +0100 (BST)
From: Nigel J. Andrews <nandrews@investsystems.co.uk>
To: pgsql-hackers@postgresql.org
Subject: A configure.in patch check
Would someone apply the attached patch to the development source and let me
know if the autoconf step fails or works. I've only got autoconf 2.13 available
and the file needs 2.53 apparently. If it works could I also have a copy of the
resulting configure script, or patch, please.
For the record, this is related to reserving the last few backend slots for the
superuser and I just need to test what I've done.
TIA
--
Nigel J. Andrews
Director
---
Logictree Systems Limited
Computer Consultants
Attachments:
configure.in.patchtext/plain; charset=US-ASCII; name=configure.in.patchDownload
Index: configure.in
===================================================================
RCS file: /projects/cvsroot/pgsql-server/configure.in,v
retrieving revision 1.197
diff -c -r1.197 configure.in
*** configure.in 2002/08/22 22:43:08 1.197
--- configure.in 2002/08/25 13:31:31
***************
*** 213,218 ****
--- 213,230 ----
#
+ # Number of connections reserved for superuser (--with-reservedbackends), default 2
+ #
+ AC_MSG_CHECKING([for default superuser reserved number of connections])
+ PGAC_ARG_REQ(with, reservedbackends, [ --with-reservedbackends=N set default superuser reserved number of connections [2]],
+ [],
+ [with_reservedbackends=2])
+ AC_MSG_RESULT([$with_reservedbackends])
+ AC_DEFINE_UNQUOTED([DEF_RESERVEDBACKENDS], [$with_reservedbackends],
+ [The default number of concurrent connection slots reserved for superusers only])
+
+
+ #
# Option to disable shared libraries
#
PGAC_ARG_BOOL(enable, shared, yes,
"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
+ AC_MSG_CHECKING([for default superuser reserved number of connections]) + PGAC_ARG_REQ(with, reservedbackends, [ --with-reservedbackends=N set default superuser reserved number of connections [2]], + [], + [with_reservedbackends=2])
This will be rejected anyway; what you want is to set up
reserved_backends as a GUC parameter, not as something that has to be
hard-wired at configure time. I can't see any reason to make it
hard-wired...
regards, tom lane
On Sun, 25 Aug 2002, Tom Lane wrote:
"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
+ AC_MSG_CHECKING([for default superuser reserved number of connections]) + PGAC_ARG_REQ(with, reservedbackends, [ --with-reservedbackends=N set default superuser reserved number of connections [2]], + [], + [with_reservedbackends=2])This will be rejected anyway; what you want is to set up
reserved_backends as a GUC parameter, not as something that has to be
hard-wired at configure time. I can't see any reason to make it
hard-wired...
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.
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? The are
global variables afterall, I think #include "miscadmin.h" would need to be
added but is that bad?
--
Nigel J. Andrews
Director
---
Logictree Systems Limited
Computer Consultants
"Nigel J. Andrews" <nandrews@investsystems.co.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