Re: FOR SHARE vs FOR UPDATE locks

Added to TODO:

* Fix problem when multiple subtransactions of the same outer transaction hold different types of locks, and one
subtransactionaborts
 
 http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php


---------------------------------------------------------------------------

Tom Lane wrote:
> Jim Nasby <decibel@decibel.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
> 
>                 http://www.postgresql.org/about/donate

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +