Re: [HACKERS] Re: Proposal for async support in libpq
От | Göran Thyni |
---|---|
Тема | Re: [HACKERS] Re: Proposal for async support in libpq |
Дата | |
Msg-id | 353DFEDD.F7BBACDB@bildbasen.se обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: Proposal for async support in libpq (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: