Re: VM corruption on standby
От | Kirill Reshke |
---|---|
Тема | Re: VM corruption on standby |
Дата | |
Msg-id | CALdSSPjGsvNPYunm7o4NB6w1gAeA_gJjzk7vgxZ0gJ8wuBAccw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: VM corruption on standby (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, 20 Aug 2025 at 00:50, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Kirill Reshke <reshkekirill@gmail.com> writes: > > I revert this commit (these were conflicts but i resolved them) and > > added assert for crit sections in WaitEventSetWait. > > Your patch still contains some conflict markers :-(. Attached is > a corrected version, just to save other people the effort of fixing > the diffs themselves. Oh, yes, it indeed contains some conflict markers, but surprisingly compiles without errors, that's why i missed it. Attached looks good to me. > > While 'make check' is okay with this assertion, 'make check-world' > still falls over if you have injection points enabled, because > src/test/modules/test_slru/t/001_multixact.pl also had the > cute idea of putting an injection-point wait inside a critical > section. I did not find any other failures though. Okay, we probably need to reimplement the wait function in injection point without latch, got it. > I'm inclined to think that we do want to prohibit WaitEventSetWait > inside a critical section --- it just seems like a bad idea all > around, even without considering this specific failure mode. > Therefore, I vote for reverting bc22dc0e0. Hopefully only > temporarily, but it's too late to figure out another way for v18, > and I don't think that bc22dc0e0 is such an essential improvement > that we can't afford to give it up for v18. +1 -- Best regards, Kirill Reshke
В списке pgsql-hackers по дате отправления: