Skip site navigation (1) Skip section navigation (2)

Re: pgwin32_open returning EINVAL

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgwin32_open returning EINVAL
Date: 2007-11-29 18:58:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > Tom Lane wrote:
> >> That analysis is full of holes --- FileRead and FileWrite for starters.
> > I already did.  The case where they retry do not call _dosmaperr.
> What's retry got to do with it?  What's displeasing me is the idea of
> LOG messages showing up during perfectly normal operation.

Oh, I see your point.  It's that those routines will sometimes be
called, they return an error, and this is *ignored* by the caller.  In
the case of FileRead, the only such caller is ExecHashJoinGetSavedTuple.

In the case of FileWrite, the thing is quite a bit more difficult to
follow, but it goes through BufFileWrite and BufFileFlush.

So yeah, it seems there is valid code trying to call FileRead and
FileWrite, have it error out, and silently ignore the error.  I'm not
going to argue this late in the cycle that all that code be changed, so
I think a reasonable compromise is to turn the ereport() in _dosmaperr
to DEBUG1 instead.  That way it won't clutter any log by default, and in
the cases where we're actually interested in tracking the problematic
situation, we don't need to get huge amounts of log traffic coming from
other parts of the system.

All the cases where BufFileFlush is called and it ignores an error are
bugs.  I think it's quite safe to modify BufFileFlush to ereport(ERROR)
if it cannot do what it was asked.

And all the callers of BufFileWrite immediately ereport() if it cannot
write the specified amount of bytes.

So there is exactly one case where these routines would be unnecessarily
noisy, and that is ExecHashJoinGetSavedTuple.

Alvaro Herrera       
"No necesitamos banderas
 No reconocemos fronteras"                  (Jorge González)

In response to


pgsql-hackers by date

Next:From: Ron MayerDate: 2007-11-29 19:11:03
Subject: Re: PG 7.3 is five years old today
Previous:From: Tom LaneDate: 2007-11-29 17:18:20
Subject: Re: pgwin32_open returning EINVAL

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group