Re: seahorse again failing - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: seahorse again failing
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA3558C@algol.sollentuna.se
Whole thread Raw
In response to Re: seahorse again failing  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: seahorse again failing
List pgsql-hackers
> >> 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.
>
> I wonder if we should add a VM column to the buildfarm machine
> specs.

Definitly. If nothing else, it should at least be listed in the platform
identificagtion. AFAIK, Snake is also a VM, and Daves other box as
well... But on VMWare (or was it Virtual Server?) and not Xen, but
still.

//Magnus


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Tricky bugs in concurrent index build
Next
From: "Dave Page"
Date:
Subject: Re: seahorse again failing