Added to TODO: * Fix problem when multiple subtransactions of the same outer transaction hold different types of locks, and one subtransaction aborts
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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
