Re: BUG #17372: Altering statistics during concurrent drop can lead to a server crash
В списке pgsql-bugs по дате отправления:
| От | Alexander Lakhin |
|---|---|
| Тема | Re: BUG #17372: Altering statistics during concurrent drop can lead to a server crash |
| Дата | |
| Msg-id | a652653f-b669-cb3a-6116-663e335a5012@gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #17372: Altering statistics during concurrent drop can lead to a server crash (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
| Список | pgsql-bugs |
Hello Tomas, 20.01.2022 20:57, Tomas Vondra wrote: > Thanks for the report - I've reproduced it using your script (I had to > add a short wait before the syscache lookup). The issue is fairly > simple, we never check we actually found a tuple in the syscache, i.e. > there's no HeapTupleIsValid() call. We check the OID earlier, but the > tuple may have disappeared since then. > > IMO the usual "cache lookup failed" error that we throw in other places > in similar cases is good enough. We already fail with other errors > (tuple concurrently updated/deleted) here. Yes, the rough, but simple search: grep -Porz '.*=\s*SearchSysCache1.*\n(?!(.*|.*\n.*|.*\n.*\n.*|.*\n.*\n.*\n.*)HeapTupleIsValid)' ./ finds only this place. Your fix works for me. Thanks! Best regards, Alexander
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера