On 19.08.24 11:43, Peter Eisentraut wrote:
On 16.08.24 23:01, Thomas Munro wrote:
On Sat, Aug 17, 2024 at 3:43 AM Peter
Eisentraut wrote:
I moved the _POSIX_C_SOURCE definition for MinGW from the header file to
a command-line option (-D_POSIX_C_SOURCE). This matches the treatment
of _GNU_SOUR
On 16.08.24 23:01, Thomas Munro wrote:
On Sat, Aug 17, 2024 at 3:43 AM Peter Eisentraut wrote:
I moved the _POSIX_C_SOURCE definition for MinGW from the header file to
a command-line option (-D_POSIX_C_SOURCE). This matches the treatment
of _GNU_SOURCE and similar.
I was trying to figure out
On Sat, Aug 17, 2024 at 3:43 AM Peter Eisentraut wrote:
> I moved the _POSIX_C_SOURCE definition for MinGW from the header file to
> a command-line option (-D_POSIX_C_SOURCE). This matches the treatment
> of _GNU_SOURCE and similar.
I was trying to figure out what else -D_POSIX_C_SOURCE does to
Here is an updated patch version.
I have changed the backend call from localtime() to gmtime() but then
also to gmtime_r().
I moved the _POSIX_C_SOURCE definition for MinGW from the header file to
a command-line option (-D_POSIX_C_SOURCE). This matches the treatment
of _GNU_SOURCE and simil
On Sat, Aug 17, 2024 at 1:09 AM Thomas Munro wrote:
> This change complements CF #5170's change strftime()->strftime_l(), to
> make the function fully thread-safe.
(Erm, I meant its standard library... of course it has its own global
variables to worry about still.)
On Tue, Jul 23, 2024 at 10:52 PM Peter Eisentraut wrote:
> Let's look at what this code actually does. It just takes the current
> time and then loops through all possible weekdays and months to collect
> and cache the localized names. The current time or time zone doesn't
> actually matter for
On 04.07.24 18:36, Heikki Linnakangas wrote:
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
local
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
On 27.06.24 06:47, Stepan Neretin wrote:
Hi! Looks good to me.
But why you don`t change localtime function at all places?
For example:
src/bin/pg_controldata/pg_controldata.c
src/bin/pg_dump/pg_backup_archiver.c
src/bin/initdb/findtimezone.c
At the moment, I am focusing on the components that a
On Thu, Jun 27, 2024 at 1:42 AM 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 librar
10 matches
Mail list logo
