Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)
Date
Msg-id 12691.1130781906@sss.pgh.pa.us
Whole thread Raw
In response to Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)
Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags
List pgsql-hackers
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> On Sun, Oct 30, 2005 at 06:17:53PM -0500, Tom Lane wrote:
>> This won't do as a permanent patch, because it isn't guaranteed to fix
>> the problem on machines that don't strongly order writes, but it should
>> work on Opterons, at least well enough to confirm the diagnosis.

> Given your proposed fix on -patches, do you still need me to test this?

Yes; we still need to verify that my theory actually explains your
problem.  Given that I'm positing that you can repeatedly hit a
two-instruction window, this is by no means a sure thing.  We need
it tested (and with asserts on, so that we can tell if it's fixed
the problem or not).

> Also, is there any heap corruption risk associated with this patch?

Look, Jim, I'm trying to help you fix this.  Are you going to help or not?
If you want some kind of written guarantee, you're not going to get one.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags
Next
From: "Jim C. Nasby"
Date:
Subject: Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",)