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

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 http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461