Re: libpq thread locking during SSL connection start

* Peter Eisentraut (peter_e(at)gmx(dot)net) wrote:
> On 8/1/13 1:42 PM, Stephen Frost wrote:
> > * Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> >> pgsecure_open_client() returns -1 if it can't lock the mutex. This is a
> >> problem because the callers are not prepared for that return value. I
> >> think it should return PGRES_POLLING_FAILED instead, after setting an
> >> appropriate error message in conn->errorMessage.
> >
> > Ah, right, adding it there was a bit of a late addition, tbh.
>
> Elsewhere in libpq, we use PGTHREAD_ERROR and abort if
> pthread_mutex_lock fails. Shouldn't we handle that consistently?

The calls which use PGTHREAD_ERROR can't return normally and have to
abort (they're callbacks).

> Alternatively, if we want to just print an error message and proceed, we
> should put the strerror based on the return value into the message.

That could certainly be added. Should we also be adding an
error message+strerror in cases where pthread_mutex_unlock() fails for
some reason?

> Overall, the response to these kinds of errors doesn't look very well
> thought through. (Not to speak of ecpg, which ignores these errors
> altogether.)

Agreed.

Thanks,

Stephen