Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion("!((itemid)->lp_flags - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion("!((itemid)->lp_flags
Date
Msg-id 200510311819.j9VIJrD12991@candle.pha.pa.us
Whole thread Raw
In response to Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] FKs on temp tables: hard, or just omitted?
Next
From: Tom Lane
Date:
Subject: Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)