Re: libpq thread locking during SSL connection start - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: libpq thread locking during SSL connection start
Date
Msg-id 20130812144940.GF2706@tamriel.snowman.net
Whole thread Raw
In response to Re: libpq thread locking during SSL connection start  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: libpq thread locking during SSL connection start
List pgsql-hackers
* Peter Eisentraut (peter_e@gmx.net) wrote:
> On 8/1/13 1:42 PM, Stephen Frost wrote:
> > * Alvaro Herrera (alvherre@2ndquadrant.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

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Updatable view columns
Next
From: "Kodamasimham Pridhvi (MT2012066)"
Date:
Subject: Re: Proposal for XML Schema Validation