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

From Tom Lane
Subject Re: windows shared memory error
Date
Msg-id 3590.1241239276@sss.pgh.pa.us
Whole thread Raw
In response to windows shared memory error  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: windows shared memory error
Re: windows shared memory error
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> I am seeing Postgres 8.3.7 running as a service on Windows Server 2003 
> repeatedly fail to restart after a backend crash because of the 
> following code in port/win32_shmem.c:

On further review, I see an entirely different explanation for possible
failures of that code.

It says here:
http://msdn.microsoft.com/en-us/library/ms885627.aspx
that GetLastError() continues to return the same error code until
someone calls SetLastError() to change it.  It further says that
only a few operating system functions call SetLastError(0) on success,
and that it is explicitly documented whenever a function does so.
I see no such statement for CreateFileMapping:
http://msdn.microsoft.com/en-us/library/aa366537(VS.85).aspx

This leads me to conclude that after a successful creation,
GetLastError will return whatever the errno previously was,
meaning that you cannot reliably distinguish creation from non
creation unless you do SetLastError(0) beforehand.  Which we don't.

Now this would only explain problems if there were some code path
through the postmaster that could leave the errno set to
ERROR_ALREADY_EXISTS (a/k/a EEXIST) when this code is reached.  I'm not
sure there is one, and I have even less of a theory as to why system
load might make it more probable to happen.  Still, this looks like a
bug from here, and repeating the create call won't fix it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Vinicius Abrahao
Date:
Subject: [OT?] how postgresql fits in
Next
From: "Dann Corbit"
Date:
Subject: Re: Throw some low-level C scutwork at me