Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",
От | Jim Nasby |
---|---|
Тема | Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)", |
Дата | |
Msg-id | D1D2D51E3BE3FC4E98598248901F759402C88F12@ausmail2k4.aus.pervasive.com обсуждение исходный текст |
Ответы |
slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)
|
Список | 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 по дате отправления: