From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: thread-safety: strerror_r() |
Date: | 2024-09-02 19:56:40 |
Message-ID: | 1276344.1725307000@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(at)eisentraut(dot)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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jehan-Guillaume de Rorthais | 2024-09-02 21:01:47 | Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails |
Previous Message | Peter Eisentraut | 2024-09-02 19:45:03 | thread-safety: strerror_r() |