| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: seahorse again failing |
| Date: | 2006-08-22 14:28:28 |
| Message-ID: | 44EB148C.7090009@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
I wonder if we should add a VM column to the buildfarm machine specs.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stefan Kaltenbrunner | 2006-08-22 14:38:23 | Re: seahorse again failing |
| Previous Message | Jim C. Nasby | 2006-08-22 14:23:31 | Re: Autovacuum on by default? |