Tom Lane wrote:
> Magnus Hagander writes:
>> Attached is an updated patch that does both of these.
>
> This looks reasonably sane to me, and I'm satisfied with the testing
> that's been done. No objection from here.
Applied.
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresq
Magnus Hagander writes:
> Attached is an updated patch that does both of these.
This looks reasonably sane to me, and I'm satisfied with the testing
that's been done. No objection from here.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.o
Am Dienstag, 23. Juni 2009 14:17:15 schrieben Sie:
> Attached is an updated patch that does both of these.
It works for me, but I could test it only with OpenSSL 0.9.8g.
Moreover I tested the SSL-renegotiation, and it works quite fine with an
engine too - as long as I don't pull the smartcard wi
Tom Lane wrote:
> Magnus Hagander writes:
>> On 22 jun 2009, at 18.05, Tom Lane wrote:
>>> I'm also a bit concerned about wrapping a struct
>>> field inside such an #if, as that's likely to cause hard-to-debug
>>> problems if two compilations read libpq-int.h with different #define
>>> environmen
Tom Lane wrote:
> Magnus Hagander writes:
>> Lars Kanis wrote:
>>> Maybe version 2 (my initial patch) could be an alternative ?
>
>> Well, based on the "we don't know which different versions of openssl
>> it'll break with", version 2 is no better than version 3 :(
>
> Yeah, if we do anything I
Tom Lane wrote:
> Magnus Hagander writes:
>> Lars Kanis wrote:
>>> Maybe version 2 (my initial patch) could be an alternative ?
>
>> Well, based on the "we don't know which different versions of openssl
>> it'll break with", version 2 is no better than version 3 :(
>
> Yeah, if we do anything I
Magnus Hagander writes:
> Lars Kanis wrote:
>> Maybe version 2 (my initial patch) could be an alternative ?
> Well, based on the "we don't know which different versions of openssl
> it'll break with", version 2 is no better than version 3 :(
Yeah, if we do anything I think it should be more like
Lars Kanis wrote:
> Am Montag, 22. Juni 2009 17:46:22 schrieben Sie:
>> Lars Kanis writes:
>>> Am Montag, 22. Juni 2009 16:38:32 schrieben Sie:
Tom Lane wrote:
> IIUC this is a pre-existing bug/limitation in an extremely seldom-used
> feature that we don't have any very good way to te
Tom Lane wrote:
> Magnus Hagander writes:
>> On 22 jun 2009, at 17.46, Tom Lane wrote:
>>> It seems like there is large potential for failure in
>>> contexts other than the one or two you are going to be able to test
>>> right now. Is there anything that can be done to reduce the risk?
>
>> I s
Am Montag, 22. Juni 2009 17:46:22 schrieben Sie:
> Lars Kanis writes:
> > Am Montag, 22. Juni 2009 16:38:32 schrieben Sie:
> >> Tom Lane wrote:
> >>> IIUC this is a pre-existing bug/limitation in an extremely seldom-used
> >>> feature that we don't have any very good way to test. So I'm not
> >>>
Magnus Hagander writes:
> On 22 jun 2009, at 17.46, Tom Lane wrote:
>> It seems like there is large potential for failure in
>> contexts other than the one or two you are going to be able to test
>> right now. Is there anything that can be done to reduce the risk?
> I share your concerns in gen
Magnus Hagander writes:
> On 22 jun 2009, at 18.05, Tom Lane wrote:
>> I'm also a bit concerned about wrapping a struct
>> field inside such an #if, as that's likely to cause hard-to-debug
>> problems if two compilations read libpq-int.h with different #define
>> environments.
> Since it's a poi
On 22 jun 2009, at 17.46, Tom Lane wrote:
Lars Kanis writes:
Am Montag, 22. Juni 2009 16:38:32 schrieben Sie:
Tom Lane wrote:
IIUC this is a pre-existing bug/limitation in an extremely seldom-
used
feature that we don't have any very good way to test. So I'm not
really
excited about try
On 22 jun 2009, at 18.05, Tom Lane wrote:
Magnus Hagander writes:
How about the attached patch? Does it work for you?
The existing references to typedef ENGINE and associated functions are
wrapped in
#if (SSLEAY_VERSION_NUMBER >= 0x00907000L) && !defined
(OPENSSL_NO_ENGINE)
I rather im
Magnus Hagander writes:
> How about the attached patch? Does it work for you?
The existing references to typedef ENGINE and associated functions are
wrapped in
#if (SSLEAY_VERSION_NUMBER >= 0x00907000L) && !defined(OPENSSL_NO_ENGINE)
I rather imagine that this patch will cause complete failure
Lars Kanis writes:
> Am Montag, 22. Juni 2009 16:38:32 schrieben Sie:
>> Tom Lane wrote:
>>> IIUC this is a pre-existing bug/limitation in an extremely seldom-used
>>> feature that we don't have any very good way to test. So I'm not really
>>> excited about trying to fix it in RC at all. The cha
Hi Magnus,
thanks for reply.
> > The following patch solves the problem:
>
> This looks good in generael to me. I remember looking at the engine code
> wondering why we didn't do that, but since I don't have a good
> environment to test that part in, I forgot about it :(
>
> Shouldn't there be an
Am Montag, 22. Juni 2009 15:55:58 schrieben Sie:
> Lars Kanis wrote:
> >> Should we not also call ENGINE_finish() and ENGINE_free() in the success
> >> path of this code? Your patch adds it to the case where we didn't get
> >> the private key, but what if we did? I assume they should also go
> >> o
Am Montag, 22. Juni 2009 16:38:32 schrieben Sie:
> Tom Lane wrote:
> > Magnus Hagander writes:
> >> A question from that then, for others, is it Ok to add a field to the
> >> PGconn structure during RC? :-) It's only in libpq-int.h, but? Comments?
> >
> > Changing PGconn internals doesn't bother m
Tom Lane wrote:
> Magnus Hagander writes:
>> A question from that then, for others, is it Ok to add a field to the
>> PGconn structure during RC? :-) It's only in libpq-int.h, but? Comments?
>
> Changing PGconn internals doesn't bother me, but ...
>
> IIUC this is a pre-existing bug/limitation i
Magnus Hagander writes:
> A question from that then, for others, is it Ok to add a field to the
> PGconn structure during RC? :-) It's only in libpq-int.h, but? Comments?
Changing PGconn internals doesn't bother me, but ...
IIUC this is a pre-existing bug/limitation in an extremely seldom-used
f
Lars Kanis wrote:
>>> The following patch solves the problem:
>> This looks good in generael to me. I remember looking at the engine code
>> wondering why we didn't do that, but since I don't have a good
>> environment to test that part in, I forgot about it :(
>>
>> Shouldn't there be an ENGINE_fr
Lars Kanis wrote:
> The following bug has been logged online:
>
> Bug reference: 4869
> Logged by: Lars Kanis
> Email address: ka...@comcard.de
> PostgreSQL version: 8.4rc1
> Operating system: Linux c1170lx 2.6.24-23-generic #1 SMP Wed Apr 1
> 21:47:28 UTC 2009 i686 GNU/Linux
The following bug has been logged online:
Bug reference: 4869
Logged by: Lars Kanis
Email address: ka...@comcard.de
PostgreSQL version: 8.4rc1
Operating system: Linux c1170lx 2.6.24-23-generic #1 SMP Wed Apr 1
21:47:28 UTC 2009 i686 GNU/Linux
Description:No proper ini
24 matches
Mail list logo
