Re: [HACKERS] Re: Proposal for async support in libpq

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Re: Proposal for async support in libpq
Дата
Msg-id 2109.893175724@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Proposal for async support in libpq  (Jan Vicherek <honza@ied.com>)
Список pgsql-hackers
Jan Vicherek <honza@ied.com> writes:
> On Fri, 17 Apr 1998, Tom Lane wrote:
>> Signaling the cancel request via OOB sounds reasonable, as long as
>> nothing else is using it and all the systems we care about support it.

>    SSH doesn't have OOB. You can't send an OOB via SSH encrypted channel.

I was afraid we'd run into something like that.

Well, here's how I see it: cancelling requests in progress is an
optional capability.  If it doesn't work on certain communication
channels I can live with that.  I would rather see that than see the
backend slowed down by checking for cancel requests sent as normal
data (without OOB).

A client app will actually have no way to tell whether a cancel request
has any effect; if the comm channel drops OOB requests on the floor,
it will look the same as if the cancel didn't get to the server until
after the server had finished the query.  So this shouldn't really
cause any software to fail anyway.

OTOH, I would not like to see NOTIFY broken when using an SSH channel,
so this is another reason not to try to use OOB for the outbound
direction.

            regards, tom lane

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Re: [QUESTIONS] Configuration problems in PostgreSQ L 6.3.2 on Linux-ELF
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] drop table inside transactions