From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Avoiding concurrent calls to bindtextdomain() |
Date: | 2024-02-05 20:03:36 |
Message-ID: | 264860.1707163416@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
According to the discussion in [1], it's not as safe as we supposed
to allow different threads to call bindtextdomain() concurrently.
Here is a patchset to prevent that by acquiring a mutex around
the libpq and ecpglib calls that are at risk.
In libpq, this would've required yet a third copy of the
Windows-specific ugliness in default_threadlock() and pgtls_init().
I didn't particularly want to do that, so I stole some ideas
from ecpglib to create a more POSIX-compliant emulation of
pthread_mutex_lock(). 0001 attached is the refactoring needed
to make that happen, and then 0002 is the actual bug fix.
0001 also gets rid of the possibility that pthread_mutex_init/
pthread_mutex_lock could fail due to malloc failure. This seems
important since default_threadlock() assumes that pthread_mutex_lock
cannot fail in practice. I observe that ecpglib also assumes that,
although it's using CreateMutex() which has documented failure
conditions. So I wonder if we ought to copy this implementation
back into ecpglib; but I've not done that here.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/18312-bbbabc8113592b78%40postgresql.org
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Clean-up-unnecessarily-Windows-dependent-code-in-.patch | text/x-diff | 5.4 KB |
v1-0002-Avoid-concurrent-calls-to-bindtextdomain.patch | text/x-diff | 5.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2024-02-05 20:28:24 | Re: On login trigger: take three |
Previous Message | Jacob Champion | 2024-02-05 18:47:52 | Re: Commitfest 2024-01 first week update |