On 26/06/2024 21:42, Peter Eisentraut wrote:
> Here is a patch for using gmtime_r() and localtime_r() instead of
> gmtime() and localtime(), for thread-safety.
>
> There are a few affected calls in libpq and ecpg's libpgtypes, which are
> probably effectively bugs, because those libraries already claim to be
> thread-safe.
+1
The Linux man page for localtime_r() says:
> According to POSIX.1-2001, localtime() is required to behave as
> though tzset(3) was called, while localtime_r() does not have this
> requirement. For portable code, tzset(3) should be called before
> localtime_r().
It's not clear to me what happens if tzset() has not been called and the
localtime_r() implementation does not call it either. I guess some
implementation default timezone is used.
In the libpq traces, I don't think we care much. In ecpg, I'm not sure
what the impact is if the application has not previously called tzset().
I'd suggest that we just document that an ecpg application should call
tzset() before calling the functions that are sensitive to local
timezone setting.
> There is one affected call in the backend. Most of the backend
> otherwise uses the custom functions pg_gmtime() and pg_localtime(),
> which are implemented differently.
Do we need to call tzset(3) somewhere in backend startup? Or could we
replace that localtime() call in the backend with pg_localtime()?
pg_gmtime() isn't thread-safe, because of the static 'gmtptr' in
gmtsub(). But we can handle that in a separate patch.
--
Heikki Linnakangas
Neon (https://neon.tech)