Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion("!((itemid)->lp_flags
От | Bruce Momjian |
---|---|
Тема | Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion("!((itemid)->lp_flags |
Дата | |
Msg-id | 200510311819.j9VIJrD12991@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)
|
Список | pgsql-patches |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Well, then what real options do we have? It seems the patch is just > > required for all branches. > > I think it would be possible to fix it in a less invasive way by taking > and releasing the ControlLock an extra time in SimpleLruReadPage and > SimpleLruWritePage. What's indeterminate about that is the performance > cost. In situations where there's not a lot of SLRU I/O traffic it's > presumably negligible, but in a case like Jim's where there's evidently > a *whole* lot of traffic, it might be a killer. To me a performance problem is much harder get reports on and to locate than a real fix to the problem. I think if a few people eyeball the patch, it is OK for application. Are backpatches significantly different? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: