Re: gettimeofday cause crash on Windows - Mailing list pgsql-bugs

Don=E2=80=99t you feel gettimeofday() implementation is incomplete in curre=
nt
state, Is there any other example of function port in PG that could lead to
crash if its related init_* function is not called earlier ?. As mentioned
by Michael, it seems not enough documented (release notes etc), at least it
need to give warning etc instead of simply crash the related process.
GetSystemTimeAsFileTime() function is less precise but it is quite fast and
less CPU intensive then GetSystemTimePreciseAsFileTime() function,
GetSystemTimePreciseAsFileTime() can effect performance of an application.
With the proposed patch, gettimeofday() function is more safe and more
versatile, a contrib may use it as per its need of precision. Thanks.

Regards,
Muhammad Asif Naeem


On Thu, Feb 12, 2015 at 6:13 PM, Andres Freund <andres@2ndquadrant.com>
wrote:

> On 2015-02-12 22:09:43 +0900, Michael Paquier wrote:
> > On Thu, Feb 12, 2015 at 9:54 PM, Andres Freund <andres@2ndquadrant.com>
> wrote:
> > > On 2015-02-12 04:48:00 -0800, Michael Paquier wrote:
> > >> I didn't follow much the thread implementing this feature, but this
> > >> commit has somewhat not taken into account the fact that the content=
s
> > >> of src/port could as well be used for the frontends, per se the
> > >> comments on top of init_win32_gettimeofday mentioning only the backe=
nd
> > >> startup, something not wrong in itself, but not completely right
> > >> either. So what we have now is an unpleasant crash trigger for any
> > >> client applications on Windows < 2k12 linking to libpqport that call
> > >> gettimeofday(). I would not be surprised that we would get bug repor=
ts
> > >> of the type "why my client binary crashes suddendly with 9.5" if we
> > >> keep the code as-is.
> > >
> > >> So ISTM that your patch does the correct thing by setting
> > >> pg_get_system_time to &GetSystemTimeAsFileTime to not break any
> > >> existing applications, and that we should as well update any in-core
> > >> binary tools to switch to the precise API
> > >
> > > I think I'd rather have it crash so people are forced to adjust the
> > > client applications. The number of things linking to pgport should be
> > > rather low.
> >
> > I'd take it on the safe side, not the hard one :)
>
> Meh. If this were libpq, I'd tend to agree, but it isn't.
>
> > FWIW, applications are not broken if they use GetSystemTimeAsFileTime,
> > simply less precise. So we should push for improvements, not mandatory
> > moves without a deprecation period.
>
> pgport isn't an actual enduser library. And we feel free to yank stuff
> in/out of it all the time.
>
> Greetings,
>
> Andres Freund
>
> --
>  Andres Freund                     http://www.2ndQuadrant.com/
>  PostgreSQL Development, 24x7 Support, Training & Services
>