public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: Tom Lane <[email protected]>
Cc: Jim Nasby <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Simon Riggs <[email protected]>
Cc: [email protected]
Subject: Re: FOR SHARE vs FOR UPDATE locks
Date: Wed, 31 Jan 2007 23:36:15 -0500 (EST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
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. +
view thread (32+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: FOR SHARE vs FOR UPDATE locks
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox