Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 5DC419FB2DB for ; Fri, 13 Apr 2007 14:01:23 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 65758-09 for ; Fri, 13 Apr 2007 14:01:19 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from main2.mycybernet.net (main2.mycybernet.net [209.222.63.140]) by postgresql.org (Postfix) with ESMTP id 75A8A9FB33B for ; Fri, 13 Apr 2007 14:01:19 -0300 (ADT) Received: from 227-54-222-209.mycybernet.net ([209.222.54.227] helo=phlogiston.dydns.org) by main2.mycybernet.net with esmtp (Exim 4.62) (envelope-from ) id 1HcP97-00043y-Sa; Fri, 13 Apr 2007 13:01:13 -0400 Received: by phlogiston.dydns.org (Postfix, from userid 1000) id 681EC4050; Fri, 13 Apr 2007 13:01:08 -0400 (EDT) Date: Fri, 13 Apr 2007 13:01:08 -0400 From: Andrew Sullivan To: Joe Cc: Andrew Sullivan , pgsql-sql@postgresql.org Subject: Re: A long-running transaction Message-ID: <20070413170108.GD31517@phlogiston.dyndns.org> References: <20070403201420.GB1519@phlogiston.dyndns.org> <461BBE33.9030807@herakles.homelinux.org> <20070410165523.GB20033@phlogiston.dyndns.org> <461C07A5.30000@herakles.homelinux.org> <20070411133407.GB22510@phlogiston.dyndns.org> <461CEF66.4010907@herakles.homelinux.org> <20070411154923.GA22771@phlogiston.dyndns.org> <461ED6C2.2010200@herakles.homelinux.org> <20070413114919.GA31083@phlogiston.dyndns.org> <1176482556.782.83.camel@pampa> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1176482556.782.83.camel@pampa> User-Agent: Mutt/1.5.9i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/147 X-Sequence-Number: 28147 On Fri, Apr 13, 2007 at 12:42:36PM -0400, Joe wrote: > > Just curious: is there a way to defeat MVCC? No. That is, > i.e., if you can lock the > database exclusively, there won't be any readers or writers? while this is true, it doesn't shut off the way writes go through the system. MVCC is rather close to the central guts of PostgreSQL. If you want to understand more about why this is the case, what the trade-off considerations are, &c., then I stronly advise you to troll through the -hackers archives. Approximately once every 8-10 months someone comes along with an idea for a change that disables MVCC in just this or that case. Most of the time, the actual effects of this are different than people think they will be -- concurrency is hard, and making changes so that it's impossible to get into a race is tricky. This is why the in-place storage management that EnterpriseDB contributed was both somewhat controversial and somewhat limited in its application. A -- Andrew Sullivan | ajs@crankycanuck.ca This work was visionary and imaginative, and goes to show that visionary and imaginative work need not end up well. --Dennis Ritchie