Andrew Dunstan wrote: > Tom Lane wrote: >> Alvaro Herrera <[EMAIL PROTECTED]> writes: >> >>> Tom Lane wrote: >>> >>>> It would be interesting to know the actual underlying Windows error >>>> code >>>> --- I see that win32error.c maps several different codes to EACCES. >>>> >> >> >>> It may be a good idea to put a elog(LOG) with the error code in the >>> failure path of AllocateFile. >>> >> >> That seems like a plan to me. I had been thinking of making >> win32error.c itself log the conversions, but that would not provide any >> context information. AllocateFile could log the file name along with >> the code, which should be enough info to associate a particular log >> entry with the actual failure. >> >> Note you should probably save and restore errno around the elog call, >> just to be safe. >> >> Could someone with access to Windows code and test this? >> >> > > All this seems good and sensible. > > I am just a little suspicious of seahorse, though, as it is running on a > Xen VM.
indeed seahorse is running under Xen - though i have no reason to believe that xen is at fault - the eventlog shows absolutly no sign of any troubles nor does the hypervisor. The only thing I would think about is that the VM might cause some subtile timing differences wrt disk-access or scheduling (xen is not exceptionally bright about cpu scheduling - so it might starve some guests sometimes). Other than that I do seem to recall that we got a number of weird looking "permission denied" errors on win32 - improving the error reporting might help to find out if there is a pattern involved somewhere. > > I wonder if we should add a VM column to the buildfarm machine specs. that would be fine with me - maybe we could add a "LDAP" symbol too since we just had some body failing after the ldap-on-windows fix ? Stefan ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq