Re: windows shared memory error
От | Tom Lane |
---|---|
Тема | Re: windows shared memory error |
Дата | |
Msg-id | 3590.1241239276@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | windows shared memory error (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: windows shared memory error
Re: windows shared memory error |
Список | 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 по дате отправления: