From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> |
Cc: | "Stefan Kaltenbrunner" <stefan(at)kaltenbrunner(dot)cc>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: seahorse again failing |
Date: | 2006-08-23 13:23:41 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCEA35595@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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?
Do you mean something as simple as this?
compiles, passes regression tests, logs this on startup of a fresh
cluster:
LOG: win32 open error on 'global/pgstat.stat': 2
(very simple - it's a file-not-found, which is expected..)
//Magnus
Attachment | Content-Type | Size |
---|---|---|
allocatefile.patch | application/octet-stream | 669 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-08-23 13:25:41 | Re: pg_upgrade: What is changed? |
Previous Message | Hannu Krosing | 2006-08-23 13:22:52 | Re: Tricky bugs in concurrent index build |