Re: BUG #5989: Assertion failure on UPDATE of big value
От | Heikki Linnakangas |
---|---|
Тема | Re: BUG #5989: Assertion failure on UPDATE of big value |
Дата | |
Msg-id | 4DAEF7E6.7080107@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: BUG #5989: Assertion failure on UPDATE of big value ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: BUG #5989: Assertion failure on UPDATE of big value
Re: BUG #5989: Assertion failure on UPDATE of big value Re: BUG #5989: Assertion failure on UPDATE of big value |
Список | pgsql-bugs |
On 20.04.2011 18:08, Kevin Grittner wrote: > "Marko Tiikkaja"<marko.tiikkaja@2ndquadrant.com> wrote: > >> TRAP: FailedAssertion("!(((bool) (((void*)(&(newTuple->t_self)) != >> ((void *)0))&& ((&(newTuple->t_self))->ip_posid != 0))))", File: >> "predicate.c", Line: 2282) > > Am investigating, and have alerted Dan, in case he hasn't noticed > this thread. The immediate fix is trivial: --- a/src/backend/access/heap/heapam.c +++ b/src/backend/access/heap/heapam.c @@ -2859,7 +2859,7 @@ l2: * Any existing SIREAD locks on the old tuple must be linked to the new * tuple for conflict detection purposes. */ - PredicateLockTupleRowVersionLink(relation, &oldtup, newtup); + PredicateLockTupleRowVersionLink(relation, &oldtup, heaptup); if (newbuf != buffer) LockBuffer(newbuf, BUFFER_LOCK_UNLOCK); But the question Tom raised about doing this even for non-serializable transactions is more serious.. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: