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)",)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: enums