Re: win32 open patch for held unlink
От | Magnus Hagander |
---|---|
Тема | Re: win32 open patch for held unlink |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE171613@algol.sollentuna.se обсуждение исходный текст |
Список | pgsql-hackers-win32 |
I think it looks good, and see no reason why it shouldn't work. But I do think you should handle permission denied errors a bit more gracefully, don't you think? Not exactly an uncommon error, and it would certainly help to get the correct errno set there so you get a decent error msg back in the caller. Probably also ERROR_PATH_NOT_FOUND. The rest can be "generalised" into one, since they don't occur very often. Also (not sure about this one - so correct me if I'm wrong), shouldn't errno be set to *something* upon error when you haven't set a specific error? You return -1, but with errno="no error"? That will give you the infamous "The error retuern was: The operation complete successfully" that I see all the time on WIndows boxen. (That I see it in other apps deos *not* mean we should emit it from postgresql :)) One other question: The _open_osfhandle docs don't really tell about how to *close* the handle. Have you verified that you don't need to create a separate close functino that will do CloseHandle() as well on it? Or do we know that the system will do that for us when we close it? (I see some google refs to _close() calling CloseHandle(), but no official docs. THere are also docs saying that you *must* call closesocket() if the handle is a socket, which would indicate the opposite... Should be tested if not already done?) //Magnus > -----Original Message----- > From: Claudio Natoli [mailto:claudio.natoli@memetrics.com] > Sent: Tuesday, March 16, 2004 4:02 AM > To: 'pgsql-patches@postgresql.org' > Cc: pgsql-hackers-win32@postgresql.org > Subject: [pgsql-hackers-win32] win32 open patch for held unlink > > > > For application to HEAD, following community review. [open.c > destined for src/port] > > Win32 people: This has been kicked around on the thread for a > bit, I've not been able to break it, but am still > uncomfortable that it appears a novel solution. If you can > see any reason why this approach should not be adopted, speak > up now (or forever hold your transactions?). > > heers, > Claudio > > --- > Certain disclaimers and policies apply to all email sent from > Memetrics. For the full text of these disclaimers and policies see > <a > href="http://www.memetrics.com/emailpolicy.html">http://www.me > metrics.com/em > ailpolicy.html</a> > > >
В списке pgsql-hackers-win32 по дате отправления: