X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 24E1A9DC9AB for ; Fri, 24 Mar 2006 09:59:46 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 15236-05 for ; Fri, 24 Mar 2006 09:59:49 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 5B1A39DC859 for ; Fri, 24 Mar 2006 09:59:42 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id 6148856431; Fri, 24 Mar 2006 07:59:47 -0600 (CST) Received: (hashcash-sendmail, from uid 1001); Fri, 24 Mar 2006 07:59:46 -0600 Date: Fri, 24 Mar 2006 07:59:46 -0600 From: "Jim C. Nasby" To: Qingqing Zhou , pgsql-performance@postgresql.org Subject: Re: WAL logging of SELECT ... INTO command Message-ID: <20060324135946.GJ90527@pervasive.com> References: <20060321122211.GU15742@pervasive.com> <1142973230.24487.501.camel@localhost.localdomain> <20060324100731.GO90527@pervasive.com> <20060324123902.GA14217@surnet.cl> <20060324130121.GE90527@pervasive.com> <20060324134720.GA25359@surnet.cl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060324134720.GA25359@surnet.cl> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060324:zhouqq@cs.toronto.edu::Nx5yVuFXJvlZkwcO:0000000000000000 0000000000000000000000003LaU X-Hashcash: 1:20:060324:pgsql-performance@postgresql.org::psHRNWHuQY/+B4il:00000 0000000000000000000000003Mil X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.108 required=5 tests=[AWL=0.108] X-Spam-Score: 0.108 X-Spam-Level: X-Archive-Number: 200603/496 X-Sequence-Number: 17933 On Fri, Mar 24, 2006 at 09:47:20AM -0400, Alvaro Herrera wrote: > Jim C. Nasby wrote: > > On Fri, Mar 24, 2006 at 08:39:02AM -0400, Alvaro Herrera wrote: > > > Jim C. Nasby wrote: > > > > > > > Why would the content of the old_table be unreliable? If we've replayed > > > > logs up to the point of the CTAS then any data that would be visible to > > > > the CTAS should be fine, no? > > > > > > > > Though, the way Tom put it in one of his replies it sounds like WAL > > > > doesn't do any kind of statement logging, only data logging. If that's > > > > the case I'm not sure that the CTAS would actually get replayed. But I > > > > suspect I'm just misunderstanding... > > > > > > The CTAS doesn't get logged (nor replayed obviously). What happens is > > > that the involved files are fsync'ed before transaction commit, AFAIR. > > > > Ahh, yes, that sounds right. Might be a nice gain to be had if there was > > some way to log the statement, but I suspect getting WAL to support that > > would be extremely non-trivial. > > None at all, at least in the current incarnation, I think, because said > query execution is dependent on the contents of the FSM, which is itself > dependent on the timing of VACUUM and other stuff. Such an action, > running with a different FSM content, can very trivially cause data > corruption. Oh, duh, because subsiquent operations will depend on the heap being in a very specific state. Oh well. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461