On Thu, Nov 29, 2007 at 09:09:47AM -0300, Alvaro Herrera wrote:
> Magnus Hagander wrote:
> > On Wed, Nov 28, 2007 at 05:20:46PM +0100, Magnus Hagander wrote:
> > > On Wed, Nov 28, 2007 at 12:24:26PM -0300, Alvaro Herrera wrote:
> > > > Martijn van Oosterhout wrote:
> > > > > On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote:
> > > > > > Can we do something like this to report the Win32 error code so that the
> > > > > > user has a higher chance of figuring out what's going on?
> > >
> > > We already do something very similar to what you're donig in
> > > backend/port/wni32/socket.c :: TranslateSocketError().
> > >
> > > So I think it's a good idea to do it, yes.
> >
> > Thinking about this some more, I think this is a better patch - we already
> > have a function that takes care of this, including both error and debug
> > logging. Anybody disagree? If not, I'll go ahead and apply it...
>
> Hmm, but this still mixes some error codes. To absolutely get the
> Windows error code you would have to be running with DEBUG5, which I
> don't think is acceptable for a production system during any interesting
> length of time ... Can we have that DEBUG5 message changed to LOG
> instead?
Maybe. I'm concerned we might end up logging a whole lot more, for cases
where it's not an actual error. For example, a file that doesn't exist
doesn't necessarily mean it's an error... I don't want to have to go
through all code-paths that end up calling that function to see if that may
be so...
We can safely drop it to some lower level DEBUG though, maybe DEBUG1?
But it is true that we have mixed error codes. But we only do that when we
know they're actually there. If we have an unknown code, we don't just
return it as EINVAL without logging (as open did before) - and that log
goes out as LOG.
(the open code already mixed two win32 codes into ENOENT already, btw)
> Or maybe have _dosmaperr receive the elevel with which to report the
> message as a parameter, and have current callers use DEBUG5, and
> pgwin32_open use LOG. That way we can backpatch it to 8.2 without
> changing current behavior.
I don't think we can, or at least should, touch the signature for
_dosmaperr(). It's a system replacment, I think we should keep the same
signature for it.
//Magnus
