Re: PGStream synchronization

Поиск
Список
Период
Сортировка
Искать
От
Oliver Jowett
Тема
Re: PGStream synchronization
Дата
Msg-id
4A95CE4B.5050107@opencloud.com
Ответ на
Список
Дерево обсуждения
PGStream synchronization Maciek Sakrejda <msakrejda@truviso.com>
Re: PGStream synchronization Oliver Jowett <oliver@opencloud.com>
Re: PGStream synchronization Maciek Sakrejda <msakrejda@truviso.com>
Re: PGStream synchronization Maciek Sakrejda <msakrejda@truviso.com>
Re: PGStream synchronization Oliver Jowett <oliver@opencloud.com>
Re: PGStream synchronization Maciek Sakrejda <msakrejda@truviso.com>
Re: PGStream synchronization Oliver Jowett <oliver@opencloud.com>
Re: PGStream synchronization Maciek Sakrejda <msakrejda@truviso.com>
Re: PGStream synchronization Oliver Jowett <oliver@opencloud.com>
Re: PGStream synchronization Maciek Sakrejda <msakrejda@truviso.com>
Re: PGStream synchronization Maciek Sakrejda <msakrejda@truviso.com>
Maciek Sakrejda wrote:

> I'm not really sure if there's another clean approach, though. I'm
> attaching a patch that takes another dirty approach, but other than
> the fact that it seems to work, I don't really like it at all. The
> basic idea is to cancel whatever you're doing before closing the
> connection: if there's an active copy, have the executor send a
> CopyFail; otherwise, have the ProtocolConnectionImpl request a query
> cancellation.

This seems a bit heavyweight because cancelling a query isn't a trivial
amount of work, and it'll happen whenever close() is called if I read
your patch correctly. 99% of apps are effectively single-threaded so it
seems expensive to always do this when it's rarely needed ..

-O
В списке pgsql-jdbc по дате отправления
От: Kris Jurka
Дата:
От: Maciek Sakrejda
Дата:
Сообщение: Re: PGStream synchronization
FAQ