Skip site navigation (1) Skip section navigation (2)

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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marko Tiikkaja <marko(dot)tiikkaja(at)2ndquadrant(dot)com>, pgsql-bugs(at)postgresql(dot)org, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Subject: Re: BUG #5989: Assertion failure on UPDATE of big value
Date: 2011-04-20 14:46:44
Message-ID: 4DAEF1D4.2000203@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugs
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

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2011-04-20 14:51:17
Subject: Re: BUG #5989: Assertion failure on UPDATE of big value
Previous:From: Tom LaneDate: 2011-04-20 14:26:44
Subject: Re: BUG #5989: Assertion failure on UPDATE of big value

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group