Re: Fix for win32 stat() problems - Mailing list pgsql-patches

From Magnus Hagander
Subject Re: Fix for win32 stat() problems
Date
Msg-id 20080409215439.2968aa88@mha-laptop
Whole thread Raw
In response to Re: Fix for win32 stat() problems  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fix for win32 stat() problems  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > Tom Lane wrote:
> >> Ick.
>
> > The reason not to do so was to avoid having to do the two filesystem
> > calls for *every* stat, instead just calling them both when we
> > actually need to use the st_size member.
>
> I don't think that's worth (a) the code uglification, or (b) the
> chance of a bug later due to someone not knowing they need the
> special version of stat().  Are there any stat() calls that are in
> sufficiently performance-critical paths that it really matters?  How
> much slower is the second call, anyway?

Not sure really, the VM I'm working on now is so slow I can't measure
these things properly anyway. Probably not enough to matter compared to
other things - I'll try it that way to see if I can notice any
significant difference.

Trying to prepare a patch that does it the normal way, but so far I'm
failing rather miserably. The *struct* stat is already redefined on
win32, so whenever I try #undef or so it conflicts with that :-( Since
there is no way to #undef only the parametrized version.

Though right now I have the backend linking properly even though a
bunch of files refer to pgwin32_safestat() and I've actually removed
the implementation of the function, so maybe I just need to go to bed...

//Magnus

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fix for win32 stat() problems
Next
From: Tom Lane
Date:
Subject: Re: Fix for win32 stat() problems