Re: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?
Date
Msg-id 20121130180412.GI3957@awork2.anarazel.de
Whole thread Raw
In response to Re: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?
List pgsql-hackers
On 2012-11-30 12:53:27 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2012-11-30 10:42:21 -0500, Tom Lane wrote:
> >> I am suspicious that it is safe, because it's pretty darn hard to
> >> believe we'd not have seen field reports of problems with triggers
> >> otherwise.  It's not like this is a seldom-executed code path.
>
> > Thats true, but I think due to the fact that the plain DELETEs do *not*
> > trigger the Assert we might just not have noticed it.
>
> OK, I've managed to reproduce an actual failure, ie VACUUM moving the
> tuple underneath the fetch.  It's not easy to do though, and the timing
> has to be *really* tight.
>
> So that's why nobody's reported the problem --- it's not happening
> often enough for anyone to see it as a repeatable issue.

Yea. I have been playing with trying to reproduce the issue as well and
I needed 3 sessions and two gdb's to cause any problem... And even then
it took me several tries to get all conditions right.

We call heap_prune* surprisingly often...

> I'll go insert a LockBuffer call.  Good catch!

Thanks.

Greetings,

Andres Freund

--Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?
Next
From: Andres Freund
Date:
Subject: Hot Standby Feedback should default to on in 9.3+