Re: BUG #5989: Assertion failure on UPDATE of big value

On 20.04.2011 17:26, Tom Lane wrote:
> "Marko Tiikkaja"<marko(dot)tiikkaja(at)2ndquadrant(dot)com> writes:
>> =# create table foo(a int[]);
>> CREATE TABLE
>
>> =# insert into foo select array(select i from generate_series(1,10000) i);
>> INSERT 0 1
>
>> =# update foo set a = a||1;
>
>> TRAP: FailedAssertion("!(((bool) (((void*)(&(newTuple->t_self)) != ((void
>> *)0))&& ((&(newTuple->t_self))->ip_posid != 0))))", File: "predicate.c",
>> Line: 2282)
>
> Reproduced here.

> Why is predicate.c getting called at all when transaction_isolation is
> not SERIALIZABLE? (Although the same crash happens when it is ...)

Because another serializable transaction that reads/updates the tuple
later needs to find the predicate lock acquired by the first
transaction, even if the transaction in the middle isn't serializable.

It's unfortunate because it imposes a performance penalty to updates
even if serializable transactions are not used. I don't think we ever
measured the impact of this. :-(

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com