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

On Mon, Oct 31, 2005 at 01:05:06PM -0500, Tom Lane wrote:
> "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).

Ok, I'll work on getting this tested. Just to clarify, if this fixes it
then the problem wouldn't occur, or would we just see a different
assert?

> > 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.

Of course not, and I'm not looking for one. On the otherhand, I don't
want to recommend something on a production system without understanding
what kind of risks are involved, and unfortunately much of this is still
over my head. I would really like to have a better idea of what the
impact of this bug is.
-- 
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