From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: libpq thread locking during SSL connection start |
Date: | 2013-08-12 14:49:40 |
Message-ID: | 20130812144940.GF2706@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* 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
From | Date | Subject | |
---|---|---|---|
Next Message | Kodamasimham Pridhvi (MT2012066) | 2013-08-12 16:25:31 | Re: Proposal for XML Schema Validation |
Previous Message | Dean Rasheed | 2013-08-12 14:27:52 | Updatable view columns |