Skip site navigation (1) Skip section navigation (2)

Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>,Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",
Date: 2005-10-28 21:25:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Oct 28, 2005 at 04:58:56PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > All of them have in common that the slotno being passed ($3 below) is in
> > SLRU_PAGE_READ_IN_PROGRESS state ... could it be a problem with lock
> > reordering?  Maybe somebody is trying to read in a page, and somebody
> > else steals the buffer from under them.  Not sure how likely is that.
> It's even more interesting than that: in all three cases,
> SlruSelectLRUPage has selected a "least recently used" page that is
> still in READ_IN_PROGRESS state (ie, we haven't finished faulting it in)
> and is recursively calling SimpleLruReadPage to wait for that condition
> to terminate.
> Apparently, Jim's setup could desperately do with a larger SLRU arena
> for pg_subtrans, because this is supposed to be a never-happen path ---
> if you can't finish loading a page before you need its slot for
> something else, you are thrashing with a capital T.
> I suppose there's a bug in this path, but I'm darned if I can see what
> it is.  There are a number of obvious inefficiencies, but those
> shouldn't be important given that this isn't supposed to happen much.
> But how's it getting to the Assert failure?

If it helps, this is a ~250G database that's (now) on an 8-way (opteron
I think) machine with 32G. shared_buffers is set to 1G. My client also
has a 4-way machine with 16G, although it seemed to be having some
issues with producing cores that were useful.
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software    work: 512-231-6117
vcard:       cell: 512-569-9461

In response to

pgsql-hackers by date

Next:From: Jim C. NasbyDate: 2005-10-28 21:28:37
Subject: Re: enums
Previous:From: Tom LaneDate: 2005-10-28 20:58:56
Subject: Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group