TAKATSUKA Haruka wrote:
Hi.
We found the unbalance of xxAlloc and xxFree at AddUserToDacl() in
src/port/exec.c (of current HEAD code).
psidUser is a pointer of the element of a TOKEN_USER structure
allocated by HeapAlloc(). The FreeSid() frees a SID allocated by
AllocateAndInitializeSid(). I
Hi.
We found the unbalance of xxAlloc and xxFree at AddUserToDacl() in
src/port/exec.c (of current HEAD code).
psidUser is a pointer of the element of a TOKEN_USER structure
allocated by HeapAlloc(). The FreeSid() frees a SID allocated by
AllocateAndInitializeSid(). I think that it is correct
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
Brendan Jurd writes:
> Here's a one-line patch to fix a regression in the new from_char code
> I introduced into 8.4.
> Versions <= 8.3 skipped over any whitespace immediately preceding any
> integer field, and this behaviour was lost in HEAD when my from_char
> patch was committed back in Septem
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
2009/6/23 Tom Lane :
> Brendan Jurd writes:
>> I should be able to get the same results by snipping an extra
>> strspace_len() characters in the new code path in
>> from_char_parse_int_len(). This ought to be a one-line fix that
>> doesn't clobber the good parts of my work so far. I'll run some
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
> >>>
Brendan Jurd writes:
> I should be able to get the same results by snipping an extra
> strspace_len() characters in the new code path in
> from_char_parse_int_len(). This ought to be a one-line fix that
> doesn't clobber the good parts of my work so far. I'll run some tests
> and then post a pat
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
2009/6/23 Tom Lane :
> I'm hesitant to fool with this post-RC, and we don't have "a couple of
> days" to wait for a fix --- 8.4.0 is scheduled to wrap on Thursday.
> However, I see that the first of these cases actually represents a
> regression from 8.3 and before; existing releases get 2009-03-01
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
Brendan Jurd writes:
> I think we can safely conclude from these results that Oracle pays no
> attention whatsoever to leading spaces in either the input string, or
> the format string.
> If we want to copy this behaviour, I think the best way forward is to
> add some code that deliberately skips
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
2009/6/22 Jeremy Ford :
> Hi Brendan.
>
> Results as requested - Oracle 10g:
Cheers for that Jeremy.
I think we can safely conclude from these results that Oracle pays no
attention whatsoever to leading spaces in either the input string, or
the format string.
If we want to copy this behaviour, I
Hi Brendan.
Results as requested - Oracle 10g:
SELECT TO_DATE(' 2009 03', 'MM') AS nospace FROM dual
NOSPACE
--
1/03/2009
1 row selected
SELECT TO_DATE(' 2009 03', ' MM') AS monthspace FROM dual
MONTHSPACE
--
1/03/2009
1 row selected
On Sat, Jun 20, 2009 at 2:17 PM, Krimstock, Roger I
(Roger) wrote:
>
> Noone's answered this. I'd really like to install Postgres on my work
> station.
I'm sorry - I thought I did, but I can't find it in my sent items folder.
Please try this update:
http://uploads.enterprisedb.com/download.php?
2009/6/22 Jeremy Ford :
> Oracle 9i:
> YEAR MONTH METHOD1 METHOD2
>
> 2009 03 1/03/2009 1/03/2009
>
> Oracle 10g:
> YEAR MONTH METHOD1 METHOD2
>
> 2009 03 1/03/2009 1/03/2009
>
Hi Jeremy,
The query you used above might not tell us
Oracle 9i:
YEAR MONTH METHOD1 METHOD2
2009 03 1/03/2009 1/03/2009
Oracle 10g:
YEAR MONTHMETHOD1 METHOD2
2009 03 1/03/20091/03/2009
Regards,
Jeremy.
On Sat, Jun 20, 2009 at 2:03 AM, Tom Lane wrote:
> Brendan Jurd
31 matches
Mail list logo
