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 44F699DCC2D for ; Wed, 22 Mar 2006 11:14:36 -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 72682-05 for ; Wed, 22 Mar 2006 11:14:39 -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 1B3E69DCC0D for ; Wed, 22 Mar 2006 11:14:30 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id CC48556423; Wed, 22 Mar 2006 09:14:35 -0600 (CST) Received: (hashcash-sendmail, from uid 1001); Wed, 22 Mar 2006 09:14:34 -0600 Date: Wed, 22 Mar 2006 09:14:34 -0600 From: "Jim C. Nasby" To: Tom Lane Cc: Simon Riggs , pgsql-performance@postgresql.org Subject: Re: WAL logging of SELECT ... INTO command Message-ID: <20060322151434.GG15742@pervasive.com> References: <20060321122211.GU15742@pervasive.com> <1142973230.24487.501.camel@localhost.localdomain> <20060322124732.GA15742@pervasive.com> <1143032914.24487.632.camel@localhost.localdomain> <20060322131910.GC15742@pervasive.com> <16480.1143039965@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16480.1143039965@sss.pgh.pa.us> 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:060322:tgl@sss.pgh.pa.us::XPXJYp1KrCujrFtM:00000000000000000000 0000000000000000000000000KHo X-Hashcash: 1:20:060322:simon@2ndquadrant.com::F5faX3evySf0jIpq:0000000000000000 0000000000000000000000002a44 X-Hashcash: 1:20:060322:pgsql-performance@postgresql.org::dbmg9oRy/+ysnng0:00000 000000000000000000000000BiIO 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/455 X-Sequence-Number: 17892 On Wed, Mar 22, 2006 at 10:06:05AM -0500, Tom Lane wrote: > "Jim C. Nasby" writes: > >> PITR wants all changes. Without PITR we can optimize certain logging > >> actions. > > > The only change here is that we're creating a new table based on the > > results of a SELECT. If that SELECT doesn't use anything that's > > non-deterministic, then the machine doing the recovery should already > > have all the data it needs, provided that we log the SELECT that was > > used in the CTAS. > > This is based on a fundamental misconception about the way PITR > log-shipping works. We log actions at the physical level (put this > tuple here), not the logical here's-the-statement-we-executed level. > The two approaches cannot mix, because as soon as there's any physical > discrepancy at all, physical-level actions would be incorrectly applied > to the slave database. Oh, so in other words, SELECT * INTO temp FROM table is inherently non-deterministic at the physical level, so the only way to be able to allow PITR to work is to duplicate all the physical changes. Darn. -- 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