Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process
От | Andres Freund |
---|---|
Тема | Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process |
Дата | |
Msg-id | 20140606220537.GC23201@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process
|
Список | pgsql-bugs |
On 2014-06-06 18:03:53 -0400, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2014-06-06 16:55:58 -0400, Alvaro Herrera wrote: > >> Uh, this is a completely different problem. We discussed long ago that > >> those pallocs in relpath() were going to cause a problem: > > > I actually don't think it's a different problem. If we'd restructure > > things so the critical sections are separate this wouldn't be a > > problem. It's imo not a particularly good idea to mdopen() inside a > > critical section either. > > The point here seems to be that lazy_vacuum_page does the visibility map > ops inside its own critical section. Why? Setting a visibility bit > doesn't seem like it's critical. Why can't we just move the > END_CRIT_SECTION() to before the PageIsAllVisible test? Yea, that's what I am proposing upthread. If we move the visibility tests out of the critical section this will get rid of the original report as well. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-bugs по дате отправления: