Re: pgwin32_open returning EINVAL

Поиск
Список
Период
Сортировка
От Trevor Talbot
Тема Re: pgwin32_open returning EINVAL
Дата
Msg-id 90bce5730712200757g6eb9ebf8r8921a566043f09c7@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgwin32_open returning EINVAL  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: pgwin32_open returning EINVAL  (Magnus Hagander <magnus@hagander.net>)
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: pgwin32_open returning EINVAL
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgwin32_open returning EINVAL