Here is a patch to get memory management to thread-safe.
The auto_allocs global variable is split into per-thread variables
and accessed separately in each thread.
This patch is including the previous cleanup patch I sent because
I found pthread_once() for Win32 has a bug; it was not thread-safe.
On Windows the OpenSSL guys have included code with 0.9.8 and above to
allow OpenSSL to work correctly regardless of the MSVC runtime libraries
that have been used with the host application. This has become noticable
with the MSVC++ build in which any client apps that connect using libpq
with a
Andrew Dunstan wrote:
Then I think I'd rather disable use of client certs for the offending
openssl versions in libpq, or let the apps die and refer the customers
to the openssl people to lobby them for a sane solution.
If this were 8.0 I'd agree, but thats not a nice solution for those
Andrew Dunstan wrote:
Dave Page wrote:
I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be compatible
with the OpenSSL binary builds (we're now using 8.0), in addition to
which there are relatively few people
Dave Page wrote:
Andrew Dunstan wrote:
Dave Page wrote:
I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be
compatible with the OpenSSL binary builds (we're now using 8.0), in
addition to which there are
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
The server doesn't seem to be affected, but the attached patch fixes the
problem for the client apps. Unfortunately it must be included in the
app itself, and not libpq.
This is pretty much in the category of they've got to be
Dave Page wrote:
Andrew Dunstan wrote:
Dave Page wrote:
I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be compatible
with the OpenSSL binary builds (we're now using 8.0), in addition to
which there are relatively
Dave Page wrote:
I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be compatible
with the OpenSSL binary builds (we're now using 8.0), in addition to
which there are relatively few people using client-side certs I'd
Dave Page [EMAIL PROTECTED] writes:
Tom Lane wrote:
Doesn't really matter. Even if we were willing to hack our own client
apps like that (which I'm not), we can *not* transfer such a requirement
onto every libpq-using application. It's just not acceptable.
*We're* not transfering any
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
The server doesn't seem to be affected, but the attached patch fixes the
problem for the client apps. Unfortunately it must be included in the
app itself, and not libpq.
This is pretty much in the category of they've got to be kidding.
On 9/28/07, Tom Lane [EMAIL PROTECTED] wrote:
Dave Page [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
Then I think I'd rather disable use of client certs for the offending
openssl versions in libpq, or let the apps die and refer the customers
to the openssl people to lobby them for a
Dave Page [EMAIL PROTECTED] writes:
The server doesn't seem to be affected, but the attached patch fixes the
problem for the client apps. Unfortunately it must be included in the
app itself, and not libpq.
This is pretty much in the category of they've got to be kidding.
I recommend sitting on
Heikki Linnakangas wrote:
Dave Page wrote:
Andrew Dunstan wrote:
Dave Page wrote:
I believe we just didn't notice it until now because the older Mingw
builds use the MSVC 6.0 runtimes which just happened to be compatible
with the OpenSSL binary builds (we're now using 8.0), in addition to
Jaime Casanova wrote:
I can understand why we have relation_openrv and try_relation_open,
but relation_open_nowait can be merged with relation_open.
Well, yes it could, but why? Keeping them separate looks slightly more
readable to me, and the change could break a lot of external modules for
no
Hi,
I can understand why we have relation_openrv and try_relation_open,
but relation_open_nowait can be merged with relation_open.
Or there is something i'm missing? attached is a patch that do the merge.
--
regards,
Jaime Casanova
Programming today is a race between software engineers
Dave Page wrote:
Is it possible to use GNUTLS on Windows?
No, I don't think so. I didn't think we accepted Martijn's(?) patch
for it anyway?
This mess might make that worth revisiting, if it can be used on
Windows. See http://josefsson.org/gnutls4win/
cheers
andrew
Marko Kreen wrote:
On 9/28/07, Tom Lane [EMAIL PROTECTED] wrote:
Dave Page [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
Then I think I'd rather disable use of client certs for the offending
openssl versions in libpq, or let the apps die and refer the customers
to the openssl people to
solaris openssl refuses to handle keys longer than 128bits.
* aes will crash on longer keys
* blowfish will silently cut the key which can result
data corruption
to fix it:
- test errors from AES functions
- bf errors cannot be tested, do test encryption
- change aes compat macros to static
Dave Page [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
Then I think I'd rather disable use of client certs for the offending
openssl versions in libpq, or let the apps die and refer the customers
to the openssl people to lobby them for a sane solution.
If this were 8.0 I'd agree, but
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
Then I think I'd rather disable use of client certs for the offending
openssl versions in libpq, or let the apps die and refer the customers
to the openssl people to lobby them for a sane solution.
If this were 8.0
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
Tom Lane wrote:
Doesn't really matter. Even if we were willing to hack our own client
apps like that (which I'm not), we can *not* transfer such a requirement
onto every libpq-using application. It's just not acceptable.
*We're* not
Dave Page wrote:
I did stumble across this text on a mailing list in response to someone
with a similar problem in some JNI code. I know little of the OpenSSL
API, but perhaps it rings bells with you before I spend my evening
trying to figure it out?
OK, I think I've figured out a fix.
Dave Page wrote:
Dave Page wrote:
I did stumble across this text on a mailing list in response to someone
with a similar problem in some JNI code. I know little of the OpenSSL
API, but perhaps it rings bells with you before I spend my evening
trying to figure it out?
OK, I think I've
Hi,
Starting from version VC7 msvc supports __FUNCTION__, so I think this
could be enabled in pg_config.h.win32, see attached diff.
-Hannes
*** ../pgsql-cvshead/src/include/pg_config.h.win32 Mon Apr 16 20:39:19 2007
--- src/include/pg_config.h.win32 Fri Sep 28 22:32:50 2007
Dave Page wrote:
Dave Page wrote:
Dave Page wrote:
I did stumble across this text on a mailing list in response to someone
with a similar problem in some JNI code. I know little of the OpenSSL
API, but perhaps it rings bells with you before I spend my evening
trying to figure it out?
OK, I
Magnus Hagander wrote:
Dave Page wrote:
Dave Page wrote:
Dave Page wrote:
I did stumble across this text on a mailing list in response to someone
with a similar problem in some JNI code. I know little of the OpenSSL
API, but perhaps it rings bells with you before I spend my evening
trying
The recent TCL patch assumed Tcl_NotifierProcs.initNotifierProc was
added in TCL 8.2:
#if HAVE_TCL_VERSION(8,2)
/*
* Override the functions in the Notifier subsystem. See comments
above.
*/
{
Tcl_NotifierProcs notifier;
Dave Page wrote:
Magnus Hagander wrote:
Dave Page wrote:
Dave Page wrote:
Dave Page wrote:
I did stumble across this text on a mailing list in response to someone
with a similar problem in some JNI code. I know little of the OpenSSL
API, but perhaps it rings bells with you before I spend my
Magnus Hagander wrote:
Hrrm. Obviously, I need to go sleep now. Sorry about that.
But it'd be nice to get rid of all those #ifdef blocks..
See the attached revision. This is untested as I don't have a linux box
to hand, but I believe it's right.
/D
Index: src/interfaces/libpq/fe-secure.c
Dave Page wrote:
Magnus Hagander wrote:
Hrrm. Obviously, I need to go sleep now. Sorry about that.
But it'd be nice to get rid of all those #ifdef blocks..
See the attached revision. This is untested as I don't have a linux box
to hand, but I believe it's right.
Ignore that - I managed to
The recent TCL patch assumed Tcl_NotifierProcs.initNotifierProc
was added in TCL 8.2:
In fact it was added in 8.4 so I have modified the CVS with
the following patch.
I confirmed this against the 8.2.5 release. Sorry I did not notice that
when I initially created the patch.
While the patch
On Friday 28 September 2007 14:04, Bruce Momjian wrote:
** 178,184
* within Postgres, but we implement all the functions for completeness.
* We can only fix this with Tcl = 8.2, when Tcl_SetNotifier() appeared.
*/
! #if HAVE_TCL_VERSION(8,2)
You missed the 8.2 in the comment.
Tom Lane wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
Patch includes documentation and new regression tests. While I was in
there I also added regression tests for quote_ident(), which appeared
to be absent.
This seems rather pointless, since it's equivalent to
Matt Newell wrote:
On Friday 28 September 2007 14:04, Bruce Momjian wrote:
** 178,184
* within Postgres, but we implement all the functions for completeness.
* We can only fix this with Tcl = 8.2, when Tcl_SetNotifier() appeared.
*/
! #if HAVE_TCL_VERSION(8,2)
You
Marshall, Steve wrote:
The recent TCL patch assumed Tcl_NotifierProcs.initNotifierProc
was added in TCL 8.2:
In fact it was added in 8.4 so I have modified the CVS with
the following patch.
I confirmed this against the 8.2.5 release. Sorry I did not notice that
when I initially created
Bruce Momjian [EMAIL PROTECTED] writes:
Marshall, Steve wrote:
This is probably not a big problem, since TCL was not commonly compiled
with multithreading enabled prior to 8.4. However, perhaps there should
be a warning in the documentation on PL/TCL directing users to avoid
linking
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Raney wrote:
Hello All,
We have prepared a patch (against CVS HEAD)for the TODO item:
* Hash
-During
Dave Page [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Is there any reason not to just do this on *all* platforms, and get rid
of all the #ifdefs?
Yes, (see the comment in the code). We stat the private key on *nix to
ensure it hasn't changed underneath us which can't be done using the
Marko Kreen [EMAIL PROTECTED] writes:
solaris openssl refuses to handle keys longer than 128bits.
...
So something like the current patch should be still applied
as a near-term fix.
Applied to HEAD and 8.2. I wasn't sure if there was interest in
patching further back, or if the patch was
On Fri, 2007-09-28 at 10:02 +0100, Heikki Linnakangas wrote:
Well, yes it could, but why? Keeping them separate looks slightly more
readable to me, and the change could break a lot of external modules for
no good reason.
I agree: it also complicates the common case (calling relation_open()
and
On 9/29/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Has anyone every asked for this functionality?
I searched the list archives for previous mentions of the topic, and
didn't find any. So the answer to your question is yes, but so far
it seems to be just me.
Cheers,
BJ
41 matches
Mail list logo
