Re: Prepared transaction releasing locks before deregistering its GID
В списке pgsql-hackers по дате отправления:
| От | Oleksii Kliukin |
|---|---|
| Тема | Re: Prepared transaction releasing locks before deregistering its GID |
| Дата | |
| Msg-id | 2AB98E72-430C-4CEF-A9EA-3F183CE2CDD1@hintbits.com обсуждение |
| Ответ на | Re: Prepared transaction releasing locks before deregistering its GID (Oleksii Kliukin <alexk@hintbits.com>) |
| Ответы |
Re: Prepared transaction releasing locks before deregistering its GID
|
| Список | pgsql-hackers |
Hi, Oleksii Kliukin <alexk@hintbits.com> wrote: > > The approach looks good to me. Surprisingly, I saw no stalled backends > because of the double acquisition of lock at TwoPhaseGetGXact once I put a > simple TwoPhaseStateLock right before the "gxact->valid = false” line; I > will test your patch and post the outcome. I gave it a spin on the same VM host as shown to constantly reproduce the issue and observed neither 'identifier already in use' nor any locking issues over a few dozens of runs, so it looks good to me. That was HEAD, but since FinishPreparedTransaction seems to be identical there and on the back branches it should work for PG 10 and 11 as well. Regards, Oleksii Kliukin
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера