On Wed, Jun 24, 2009 at 16:01, Magnus Hagander wrote:
> Andrew Chernow wrote:
>>
>>> The only issue now is a small leak of memory in a function that is only
>>> called a fixed (and very small) number of times per process. Given this,
>>> I'm inclined to say we should put it on hold for 8.5. Thought
Andrew Chernow wrote:
>
>> The only issue now is a small leak of memory in a function that is only
>> called a fixed (and very small) number of times per process. Given this,
>> I'm inclined to say we should put it on hold for 8.5. Thoughts?
>>
>>
>
> Doesn't sound urgent to me. If it were my de
The only issue now is a small leak of memory in a function that is only
called a fixed (and very small) number of times per process. Given this,
I'm inclined to say we should put it on hold for 8.5. Thoughts?
Doesn't sound urgent to me. If it were my decision, I'd punt it to 8.5.
Hard to k
Andrew Chernow wrote:
>>
>> Attached is a mix of our two patches. How does that look to you?
>>
>
> looks good.
The next obvious question is, is this something we care to backpatch (at
this point, 8.4 is considered backpatch from that perspective), or
should we hold for 8.5?
The only issue now i
Attached is a mix of our two patches. How does that look to you?
looks good.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Andrew Chernow wrote:
>
>>
>> How about something like this? I switched to using LocalAlloc() in all
>> places to be consistent, instead of mixing heap and local. (Though per
>> doc, LocalAlloc is actually a wrapper for HeapAlloc in win32).
>
> Our patches crossed. Although, in my patch I left t
How about something like this? I switched to using LocalAlloc() in all
places to be consistent, instead of mixing heap and local. (Though per
doc, LocalAlloc is actually a wrapper for HeapAlloc in win32).
Our patches crossed. Although, in my patch I left the allocation scheme
alone since I
DWORD len = GetLengthSid(pTokenUser->User.Sid)
*ppSidUser = (PSID) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len);
CopySid(len, *ppSidUser, pTokenUser->User.Sid);
I attached a patch for this. Although, I did not use CopySid. Instead,
I changed GetUserSid to GetTokenUser. AddUserToDacl(
Andrew Chernow wrote:
> 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 al
At present, a specific error, crash or trouble seems not to have
happened.
The reason its not crashing is that most, if not all, windows allocation
functions know which addresses belong to them. FreeSid is actually
documented as returning NULL on success. On failure it returns the
address
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
12 matches
Mail list logo
