Re: windows shared memory error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: windows shared memory error
Date: 2009-05-02 04:41:16
Message-ID: 3590.1241239276@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dann Corbit 2009-05-02 06:06:05 Re: Throw some low-level C scutwork at me
Previous Message Vinicius Abrahao 2009-05-02 01:40:22 [OT?] how postgresql fits in