pgsql: Implement error checking for pthreads calls in thread-safe mode.
Log Message:
-----------
Implement error checking for pthreads calls in thread-safe mode. They really
should always succeed, but in the likely event of a failure we would
previously fall through *without locking* - the new code will exit(1).
Printing the error message on stderr will not work for all applications, but
it's better than nothing at all - and our API doesn't provide a way to return
the error to the caller.
Modified Files:
--------------
pgsql/src/interfaces/libpq:
fe-connect.c (r1.357 -> r1.358)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-connect.c?r1=1.357&r2=1.358)
fe-secure.c (r1.104 -> r1.105)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-secure.c?r1=1.104&r2=1.105)
libpq-int.h (r1.129 -> r1.130)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/libpq-int.h?r1=1.129&r2=1.130)
pthread-win32.c (r1.15 -> r1.16)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/pthread-win32.c?r1=1.15&r2=1.16)
"Magnus Hagander" <mha@postgresql.org> writes:
Log Message:
-----------
Implement error checking for pthreads calls in thread-safe mode. They really
should always succeed, but in the likely event of a failure we would
previously fall through *without locking* - the new code will exit(1).Printing the error message on stderr will not work for all applications, but
it's better than nothing at all - and our API doesn't provide a way to return
the error to the caller.
If you want to print an error I think you have to use write(2) here instead of
fprintf. if pthread is cocked up then fprintf is going to have trouble locking
the buffer.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning