Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",
| От | Jim C. Nasby |
|---|---|
| Тема | Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)", |
| Дата | |
| Msg-id | 20051028215532.GB13187@pervasive.com обсуждение исходный текст |
| Ответ на | Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)", (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",
|
| Список | pgsql-hackers |
On Fri, Oct 28, 2005 at 05:45:51PM -0400, Tom Lane wrote: > I wrote: > > 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? > > While I'm disinclined to change anything until we can explain why it's > crashing, I suspect that the solution may be to avoid the recursive call > of SimpleLruReadPage, as in the attached patch. 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? 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. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
В списке pgsql-hackers по дате отправления: