Re: pgwin32_open returning EINVAL - Mailing list pgsql-hackers

From Trevor Talbot
Subject Re: pgwin32_open returning EINVAL
Date
Msg-id 90bce5730712200757g6eb9ebf8r8921a566043f09c7@mail.gmail.com
Whole thread Raw
In response to Re: pgwin32_open returning EINVAL  (Magnus Hagander <magnus@hagander.net>)
Responses Re: pgwin32_open returning EINVAL  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On 12/20/07, Magnus Hagander <magnus@hagander.net> wrote:
> On Thu, Dec 20, 2007 at 04:39:55AM -0800, Trevor Talbot wrote:
> > On 12/20/07, Magnus Hagander <magnus@hagander.net> wrote:

> > > ereport(WARNING,
> > >     (errmsg("could not open file \"%s\": %s violation", fileName,
> > >           (GetLastError() ==
> > > ERROR_SHARING_VIOLATION)?_("sharing"):_("lock")),
> > >          errdetail("Continuing to retry for 30 seconds."),
> > >          errhint("You may have antivirus, backup or similar software
> > > interfering with the database.")));

> > Without looking myself, is it possible for errhint() or errdetail() to
> > do something that affects GetLastError()? It's like errno, checking it
> > very far away from the call site makes me nervous.

> Wouldn't we then have the same problem for every place that does a %i and
> report GetLastError() or errno? And we have a *lot* of those... I would've
> thought the framework thinks of that, but I haven't actually verified that.

A function's arguments are evaluated before the call, so that's safe
in general. What is implementation-specific is the order of evaluation
of different arguments, and I don't know if the parentheses above
override that.


On 12/20/07, Magnus Hagander <magnus@hagander.net> wrote:
> On Thu, Dec 20, 2007 at 10:11:10AM -0500, Tom Lane wrote:

> > Hmm ... the macro framework is designed so that the arguments get
> > evaluated before anything very interesting happens, but it might be
> > better to use a variable anyway --- for onm thing we could get rid of
> > the redundant GetLastError calls in the test in front of this.

Sounds like it was already thought of then.

> I'd expect the compiler to optimize away those, but I'll make it a var
> anyawy.

It can't; it's an opaque callout to kernel32.dll, and there's nothing
that tells the optimizer when you can expect to get the same result.
That said, it's cheaper than it looks, since the error code is stored
at a fixed location in thread-specific VM space. I guess it wasn't
interesting enough to make an MSVC intrinsic instead of keeping it a
system detail.


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: pgwin32_open returning EINVAL
Next
From: Tom Lane
Date:
Subject: Re: pgwin32_open returning EINVAL