On Thu, Sep 22, 2016 at 10:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapil...@gmail.com> writes: >> On Tue, Sep 20, 2016 at 10:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> ISTM both the previous coding and this version can fail for no good >>> reason, that is what if GetLastError() happens to return one of these >>> error codes as a result of some unrelated failure from before this >>> subroutine is entered? That is, wouldn't it be a good idea to >>> do SetLastError(0) before calling CreateFileMapping? > >> Yes, that seems like a good idea. Do you need a patch with some >> testing on windows environment? > > Please; I can't test it. >
Attached patch tightens the error handling. However, on debugging, I found that CreateFileMapping() always set error code to 0 on success. Basically, before calling CreateFileMapping(), I have set the error code as 10 (SetLastError(10)) and then after CreateFileMapping(), it sets the error code to 0 on success and appropriate error code on failure. I also verified that error code is set to 10 by calling GetLastError() before CreateFileMapping(). Now, it is quite possible that error code is set to 0 on success in my windows environment (Win7) and doesn't work in some other environment. In any case, if we want to go ahead and don't want to rely on CreateFileMapping(), then attached patch should suffice the need. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
clear_errorcode_dsm-v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers