Re: seahorse again failing

Andrew Dunstan wrote:
> Tom Lane wrote:
>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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