Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id D9BF79FA26D for ; Thu, 1 Feb 2007 00:36:21 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 33311-03 for ; Thu, 1 Feb 2007 00:36:18 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from momjian.us (momjian.us [70.90.9.53]) by postgresql.org (Postfix) with ESMTP id EC9EB9F9ECA for ; Thu, 1 Feb 2007 00:36:17 -0400 (AST) Received: (from bruce@localhost) by momjian.us (8.11.6/8.11.6) id l114aFm15778; Wed, 31 Jan 2007 23:36:15 -0500 (EST) From: Bruce Momjian Message-Id: <200702010436.l114aFm15778@momjian.us> Subject: Re: FOR SHARE vs FOR UPDATE locks In-Reply-To: <5315.1165334613@sss.pgh.pa.us> To: Tom Lane Date: Wed, 31 Jan 2007 23:36:15 -0500 (EST) CC: Jim Nasby , Heikki Linnakangas , Alvaro Herrera , Simon Riggs , pgsql-hackers@postgresql.org X-Mailer: ELM [version 2.4ME+ PL123] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200702/2 X-Sequence-Number: 97555 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 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. +