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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process