Re: seahorse again failing

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

In response to

Responses

Browse pgsql-hackers by date

  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