On 20.04.2011 17:26, Tom Lane wrote:
"Marko Tiikkaja"<marko.tiikk...@2ndquadrant.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
