Re: Hot Standby query cancellation and Streaming Replication integration
В списке pgsql-hackers по дате отправления:
| От | Robert Haas |
|---|---|
| Тема | Re: Hot Standby query cancellation and Streaming Replication integration |
| Дата | |
| Msg-id | 603c8f071002260945t82f6f3dt67ceca34ba9f9287@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Hot Standby query cancellation and Streaming Replication integration (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
| Список | pgsql-hackers |
On Fri, Feb 26, 2010 at 10:21 AM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > 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). Wow, that seems like it would help a lot. Although I'm not 100% sure I follow all the details of how this works. ...Robert
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера