Re: [PATCHES] cypg.dll, libpq_a, initdb max_connections 60
Reini Urban [EMAIL PROTECTED] writes:
With this patch we might want to rename libpq.a to libpq.dll.a in our
install step later.
Isn't .dll.a a contradiction in terms? This doesn't seem
well-thought-out at all to me. Also the end result would have to
be much more invasive than you suggest here, since there are many
more programs besides pg_ctl that use libpq.
+ #ifdef __CYGWIN__
+ static const int conns[] = {60, 50, 40, 30, 20, 10, 5};
+ #else
static const int conns[] = {100, 50, 40, 30, 20, 10};
+ #endif
This part is just silly. If your system can't support ten connections
I think you need to fix your system. Also, we are not in the habit of
plastering the source with platform-specific ifdefs just to save a
couple of cycles during initialization. If the probe at 100 caused an
actual failure on cygwin, I'd accept such a patch, but not otherwise.
How legible do you think this code would be if we tried to #ifdef in
platform-specific limits for every port we support?
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] cypg.dll, libpq_a, initdb max_connections 60
Tom Lane schrieb:
Reini Urban [EMAIL PROTECTED] writes:
With this patch we might want to rename libpq.a to libpq.dll.a in our
install step later.
Isn't .dll.a a contradiction in terms? This doesn't seem
well-thought-out at all to me. Also the end result would have to
be much more invasive than you suggest here, since there are many
more programs besides pg_ctl that use libpq.
.dll.a: well, that's the fact.
I had terrible problems in compiling apps which link to libpq.a, which
actually is libtool problem. it's has very very low urgency.
invasiveness: see the libpq_a patch.
I wonder why you link all clients statically. with a libpq macro you
could decide to which version (shared or static) you want to link against.
+ #ifdef __CYGWIN__
+ static const int conns[] = {60, 50, 40, 30, 20, 10, 5};
+ #else
static const int conns[] = {100, 50, 40, 30, 20, 10};
+ #endif
This part is just silly. If your system can't support ten connections
I think you need to fix your system. Also, we are not in the habit of
plastering the source with platform-specific ifdefs just to save a
couple of cycles during initialization. If the probe at 100 caused an
actual failure on cygwin, I'd accept such a patch, but not otherwise.
How legible do you think this code would be if we tried to #ifdef in
platform-specific limits for every port we support?
arguments accepted.
though the probe for cygwin at 100 causes it NOT to fail.
this is actually a more severe problem.
It'll stay in my private patches archive.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] cypg.dll, libpq_a, initdb max_connections 60
1. cyg-pgdll.patch For the cygwin port I found out that we'd need a better name for libpq libraries only, and that the name pq.dll is not a good one. It would clash with the mingw version, which might get copied into the path. We have out own standards, esp. when dealing with import libs, which would require the cyg prefix for pq.dll. The mingw library is libpq.dll, not pq.dll. If cygwin uses just pq.dll there will be no clash. Same for the native win32 version, which has been around for years. //Magnus ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
