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


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jim Nasby <decibel(at)decibel(dot)org>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FOR SHARE vs FOR UPDATE locks
Date: 2007-02-01 04:36:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-docspgsql-hackers
Added to TODO:

* Fix problem when multiple subtransactions of the same outer transaction
  hold different types of locks, and one subtransaction aborts


Tom Lane wrote:
> Jim Nasby <decibel(at)decibel(dot)org> writes:
> > As for possibly using the in-memory store of multiple CIDs affecting  
> > a tuple, could that not work if that store contained enough  
> > information to 'rollback' the lock to it's original state when  
> > restoring to a savepoint? AFAIK other backends would only need to  
> > know what the current lock being held was, they wouldn't need to know  
> > the history of it themselves...
> One of the interesting problems is that if you upgrade shared lock to
> exclusive and then want to roll that back, you might need to un-block
> other processes that tried to acquire share lock after you acquired
> exclusive.  We have no way to do that in the current implementation.
> (Any such processes will be blocked on your transaction ID lock, which
> you can't release without possibly unblocking the wrong processes.)
> 			regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at

  Bruce Momjian   bruce(at)momjian(dot)us

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-docs by date

Next:From: Bruce MomjianDate: 2007-02-01 21:03:27
Subject: File system replication and DRBD
Previous:From: Bruce MomjianDate: 2007-02-01 03:18:15
Subject: Re: v8.2 US documentation

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2007-02-01 04:41:09
Subject: Re: pg_restore fails with a custom backup file
Previous:From: Chris DunlopDate: 2007-02-01 04:03:05
Subject: Re: Data archiving/warehousing idea

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