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

From Peter Eisentraut
Subject Re: libpq thread locking during SSL connection start
Date
Msg-id 5208E29B.5030105@gmx.net
Whole thread Raw
In response to Re: libpq thread locking during SSL connection start  (Stephen Frost <sfrost@snowman.net>)
Responses Re: libpq thread locking during SSL connection start  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
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?

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.

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.)




pgsql-hackers by date:

Previous
From: Pavel Raiskup
Date:
Subject: [PATCH] Re: [BUGS] BUG #7815: Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/postgreql-setup fails - invalid status retrieve
Next
From: Bruce Momjian
Date:
Subject: Re: [BUGS] BUG #8335: trim() un-document behaviour