Re: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?
От | Andres Freund |
---|---|
Тема | Re: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger? |
Дата | |
Msg-id | 20121130180412.GI3957@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?
|
Список | 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 по дате отправления: