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 по дате отправления: