Re: Hot Standby query cancellation and Streaming Replication integration
В списке pgsql-hackers по дате отправления:
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Hot Standby query cancellation and Streaming Replication integration |
| Дата | |
| Msg-id | 4B87E6DF.2030501@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: Hot Standby query cancellation and Streaming Replication integration (Richard Huxton <dev@archonet.com>) |
| Ответы |
Re: Hot Standby query cancellation and Streaming
Replication integration
|
| Список | pgsql-hackers |
Richard Huxton wrote: > Can we not wait to cancel the transaction until *any* new lock is > attempted though? That should protect all the single-statement > long-running transactions that are already underway. Aggregates etc. Hmm, that's an interesting thought. You'll still need to somehow tell the victim backend "you have to fail if you try to acquire any more locks", but a single per-backend flag in the procarray would suffice. You could also clear the flag whenever you free the last snapshot in the transaction (ie. between each query in read committed mode). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера