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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-04-20 14:51:17 | Re: BUG #5989: Assertion failure on UPDATE of big value |
Previous Message | Tom Lane | 2011-04-20 14:26:44 | Re: BUG #5989: Assertion failure on UPDATE of big value |