Re: [HACKERS] Proposal for async support in libpq - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Proposal for async support in libpq
Date
Msg-id 9169.893030265@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Proposal for async support in libpq  (ocie@paracel.com)
List pgsql-hackers
ocie@paracel.com writes:
> When the Postgresql library installs its signal handler for SIGURG, it
> can find out if one was already in place.  If so, it can check to see
> if the SIGURG is for that other handler and the postgres handler can
> call the other handler.

Cool ... but what makes you think that you get to go second?  The app
could install or remove its SIGURG handler at any time.

Also, how would you tell whether the SIGURG was "for that other
handler"?  As Bruce pointed out, the signal may be delivered before any
OOB data is actually available to be read; therefore there is no way for
the signal handler to be sure whether the SIGURG came off the postgres
socket or some other one.

Basically, the Unix interface to OOB data is too brain-damaged to
be useful with more than one source of OOB data :-(.  We can usefully
use it in the backend, because we can just declare that that's all the
backend will ever use OOB input for.  But I don't think we can make
the same choice for frontend applications.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Proposal for async support in libpq
Next
From: "Jose' Soares Da Silva"
Date:
Subject: errors on transactions and locks ?