Tom Lane wrote:
>
> Jan Vicherek <honza@ied.com> writes:
> > 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.
>
We could use some kind of threaded model,
with the main thread running the current execution path
and a minimal thread just "select:ing on the socket".
A 2 process model would be most portable,
a pthread solution would be cleaner.
NOTIFY/CANCEL could be an option for modern
(in this case, pthreading) systems only.
regards,
--
---------------------------------------------
Göran Thyni, sysadm, JMS Bildbasen, Kiruna
