Re: thread-safety: strerror_r() - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: thread-safety: strerror_r()
Date
Msg-id 855d71a1-7470-4eb5-8340-574146827700@eisentraut.org
Whole thread Raw
In response to Re: thread-safety: strerror_r()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 02.09.24 21:56, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> I think we can apply these patches now to check this off the list of
>> not-thread-safe functions to check.
> 
> +1 for the first patch.  I'm less happy with
> 
> -    static char errbuf[36];
> +    static char errbuf[128];
> 
> As a minor point, shouldn't this be
> 
> +    static char errbuf[PG_STRERROR_R_BUFLEN];
> 
> But the bigger issue is that the use of a static buffer makes
> this not thread-safe, so having it use strerror_r to fill that
> buffer is just putting lipstick on a pig.  If we really want
> to make this thread-ready, we need to adopt the approach used
> in libpq's fe-secure-openssl.c, where callers have to free the
> buffer later.  Or maybe we could just palloc the result, and
> trust that it's not in a long-lived context?

Ok, I have committed the first patch.  We can think about the best 
solution for the second issue when we get to the business end of all 
this.  The current situation doesn't really prevent making any progress 
on that.




pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: Optimize mul_var() for var1ndigits >= 8
Next
From: Bertrand Drouvot
Date:
Subject: Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes