Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune()
От | Robert Haas |
---|---|
Тема | Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() |
Дата | |
Msg-id | CA+TgmoaNyZcPEd3ZA+5ZbuQnivS_1L=OTtRNv15tK6YDJZeOEA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune()
|
Список | pgsql-bugs |
On Sun, Apr 7, 2024 at 6:00 AM Alexander Lakhin <exclusion@gmail.com> wrote: > I've refreshed the script and simplified it a bit not to use Linux > specifics. Thanks. I was able to reproduce this today on macOS 13.6.2 with REL_14_0. It didn't seem like it reproduced as quickly for me as it did for you, but I got it to fail an assertion eventually. Then my debugging efforts were frustrated by http://postgr.es/m/CA+TgmobW9bEuvSrQR1D1K6_8=DmY2tzkuepAjCWF=j4B1w0rWw@mail.gmail.com - gah > But on dad1539ae I got no failures for 3 runs (the same is on > REL_16_STABLE with a slightly modified lazy_scan_prune patch). I'm having trouble understanding what this means exactly -- are you talking about REL_16_STABLE, or about dad1539ae, or both, or what? At any rate, it's really important here that we understand whether we still have a bug here, and if so, in which releases and with what test case. I wasn't aware of dad1539ae but that certainly seems like it might've made a big difference, if not fixing the problem entirely then at least making it a lot less likely. And I think it's possible that some of the related freezing+pruning commits on master might have removed the problem altogether, but that needs to be tested. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: