database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Remove libpq's use of abort(3) to handle mutex failure cases.

Browse Source 
Doing an abort() seems all right in development builds, but not in
production builds of general-purpose libraries.  However, the functions
that were doing this lack any way to report a failure back up to their
callers.  It seems like we can just get away with ignoring failures in
production builds, since (a) no such failures have been reported in the
dozen years that the code's been like this, and (b) failure to enforce
mutual exclusion during fe-auth.c operations would likely not cause any
problems anyway in most cases.  (The OpenSSL callbacks that use this
macro are obsolete, so even less likely to cause interesting problems.)

Possibly a better answer would be to break compatibility of the
pgthreadlock_t callback API, but in the absence of field problem
reports, it doesn't really seem worth the trouble.

Discussion: https://postgr.es/m/3131385.1624746109@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2021-06-29 11:31:08 -04:00
parent 48cb244fb9
commit aaddf6ba09
3 changed files with 15 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
src/interfaces/libpq/fe-secure-openssl.c
View File

@ -611,15 +611,20 @@ static pthread_mutex_t *pq_lockarray;
static void
pq_lockingcallback(int mode, int n, const char *file, int line)
{
/*
* There's no way to report a mutex-primitive failure, so we just Assert
* in development builds, and ignore any errors otherwise. Fortunately
* this is all obsolete in modern OpenSSL.
*/
if (mode & CRYPTO_LOCK)
{
if (pthread_mutex_lock(&pq_lockarray[n]))
PGTHREAD_ERROR("failed to lock mutex");
Assert(false);
}
else
{
if (pthread_mutex_unlock(&pq_lockarray[n]))
PGTHREAD_ERROR("failed to unlock mutex");
Assert(false);
}
}
#endif /* ENABLE_THREAD_SAFETY && HAVE_CRYPTO_LOCK */