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: | 200702010436.l114aFm15778@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
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 <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
>
> http://www.postgresql.org/about/donate
--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-02-01 21:03:27 | File system replication and DRBD |
Previous Message | Bruce Momjian | 2007-02-01 03:18:15 | Re: v8.2 US documentation |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-02-01 04:41:09 | Re: pg_restore fails with a custom backup file |
Previous Message | Chris Dunlop | 2007-02-01 04:03:05 | Re: Data archiving/warehousing idea |