Обсуждение: 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