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

From Tom Lane
Subject Re: [HACKERS] Re: Proposal for async support in libpq
Date
Msg-id 2109.893175724@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal for async support in libpq  (Jan Vicherek <honza@ied.com>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: [QUESTIONS] Configuration problems in PostgreSQ L 6.3.2 on Linux-ELF
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] drop table inside transactions