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:59:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On 20.04.2011 17:51, Tom Lane wrote:
> 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.

There's *three* transactions here. The first one is serializable, and 
reads the tuple. The second one is not serializable, and updates it. The 
third one is serializable and updates it again.

The second transaction needs to copy the predicate lock held by the 
first transaction to the new row version, so that the third transaction 
that updates it again sees the lock.

Or, we document that any non-serializable updates will break the 
serialization protection for any other transactions accessing the same rows.

   Heikki Linnakangas

In response to


pgsql-bugs by date

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

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