Re: [HACKERS] Proposal for async support in libpq

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Proposal for async support in libpq
Дата
Msg-id 9169.893030265@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Proposal for async support in libpq  (ocie@paracel.com)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Proposal for async support in libpq
Следующее
От: "Jose' Soares Da Silva"
Дата:
Сообщение: errors on transactions and locks ?