Re: windows shared memory error - Mailing list pgsql-hackers

From Tom Lane
Subject Re: windows shared memory error
Date
Msg-id 11254.1241361268@sss.pgh.pa.us
Whole thread Raw
In response to Re: windows shared memory error  (Magnus Hagander <magnus@hagander.net>)
Responses Re: windows shared memory error
Re: windows shared memory error
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>> It says here:
>> http://msdn.microsoft.com/en-us/library/ms885627.aspx

> FWIW, this is the Windows CE documentation. The one for win32 is at:
> http://msdn.microsoft.com/en-us/library/ms679360(VS.85).aspx

Sorry, that was the one that came up first in a Google search ...

> The ref page for CreateFileMapping you linked has:

> "If the object exists before the function call, the function returns a
> handle to the existing object (with its current size, not the specified
> size), and GetLastError  returns ERROR_ALREADY_EXISTS. "

> I think that qualifies as it documenting that it's setting the return
> value, no?

The question is what it does when creating a new object.  To be sure
that our existing code isn't misled, it'd be necessary for
CreateFileMapping to do SetLastError(0) in the successful-creation
code path.  What I read the GetLastError page to be saying is that
most functions do *not* do SetLastError(0) on success, and that it
is always documented if they do.

> The quick try would be to stick a SetLastError(0) in there, just to be
> sure... Could be worth a try?

I kinda think we should do that whether or not it can be proven to
have anything to do with Andrew's report.  It's just like "errno = 0"
for Unix --- sometimes you have to do it to be sure of whether a
particular function has thrown an error.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: windows shared memory error
Next
From: Robert Haas
Date:
Subject: cleaning up stray references