| От | Peter Eisentraut |
|---|---|
| Тема | Re: Cancelling parallel query leads to segfault |
| Дата | |
| Msg-id | eb52b99b-c4db-0b39-fea9-7c89f806a34e@2ndquadrant.com обсуждение исходный текст |
| Ответ на | Cancelling parallel query leads to segfault (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Cancelling parallel query leads to segfault
|
| Список | pgsql-hackers |
On 1/27/18 22:45, Andres Freund wrote: > I think the comment was bad, but the functionality pretty crucial. So I > don't think > In AtAbort_Portals(), remove the code that marks an active portal as > failed. As the comment there already predicted, this doesn't work if > the running command wants to keep running after transaction abort. And > it's actually not necessary, because pquery.c is careful to run all > portal code in a PG_TRY block and explicitly runs MarkPortalFailed() if > there is an exception. So the code in AtAbort_Portals() is never used > anyway. > holds true, because FATAL errors do not follow the sigsetjmp chain. > > I'm uncomfortable with the idea, but without further study, it does seem > like you might be able to largely rescue the idea by checking > proc_exit_in_progress or similar. Here is a patch to implement that idea. Do you have a way to test it repeatedly, or do you just randomly cancel queries? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера