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

From Jim Nasby
Subject Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",
Date
Msg-id D1D2D51E3BE3FC4E98598248901F759402C88F12@ausmail2k4.aus.pervasive.com
Whole thread Raw
Responses slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)
List pgsql-hackers
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
> > On Fri, Oct 28, 2005 at 05:45:51PM -0400, Tom Lane wrote:
> >> Jim, are you interested
> >> in seeing if this patch makes the problem go away for you?
>
> > Well, this is a production system... what's the risk with
> that patch?
>
> Well, it's utterly untested, which means it might crash your system,
> which is where you are now, no?

Yes, but the crashes are somewhat sporadic and most importantly they don't appear to involve any data loss/corruption.
Ijust don't want to make matters any worse. 

In any case, my client's gone home for the weekend, so I doubt anything would happen until Monday.

> > BTW, is it typical to see a 10 difference between asserts
> on and off? My
> > client has a process that was doing 10-20 records/sec with
> asserts on
> > and 90-110 with asserts off.
>
> Not typical, but I can believe there are some code paths like that.

Yeah, they're doing some not-so-good things like row-by-row operations, so that's probably what the issue is. I seem to
recall20% being the penalty that's normally thrown around, so I was just surprised by such a huge difference. 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",
Next
From: Rod Taylor
Date:
Subject: Re: enums