Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Keith Fiske <keith(at)omniti(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, levertond(at)googlemail(dot)com, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process
Date: 2014-06-06 22:05:37
Message-ID: 20140606220537.GC23201@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2014-06-06 18:03:53 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2014-06-06 22:21:45 Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process
Previous Message Tom Lane 2014-06-06 22:03:53 Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process