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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
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:51:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> On 20.04.2011 17:26, Tom Lane wrote:
>> 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.

Sorry, that argument doesn't pass the sniff test.  If the transaction in
the middle isn't serializable, then it is not the same as the "first
transaction", which means that the first transaction is completed and
can no longer be holding any locks.

> 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. :-(

This feature was sold to us on the grounds that it wouldn't impose any
performance penalty when not in use.  Not having bothered to measure
the performance penalty isn't passing the sniff test either.

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: Allen SooredooDate: 2011-04-20 14:55:16
Subject: BUG #5990: 100% CPU reached
Previous:From: Heikki LinnakangasDate: 2011-04-20 14:46:44
Subject: Re: BUG #5989: Assertion failure on UPDATE of big value

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