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 72D939DC83C for ; Wed, 22 Mar 2006 11:35:26 -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 77195-08 for ; Wed, 22 Mar 2006 11:35:30 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 1E4F29DC9F7 for ; Wed, 22 Mar 2006 11:35:23 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id k2MFZQAk016693; Wed, 22 Mar 2006 10:35:26 -0500 (EST) To: "Jim C. Nasby" cc: Simon Riggs , pgsql-performance@postgresql.org Subject: Re: WAL logging of SELECT ... INTO command In-reply-to: <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> <20060322151434.GG15742@pervasive.com> Comments: In-reply-to "Jim C. Nasby" message dated "Wed, 22 Mar 2006 09:14:34 -0600" Date: Wed, 22 Mar 2006 10:35:26 -0500 Message-ID: <16692.1143041726@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.113 required=5 tests=[AWL=0.113] X-Spam-Score: 0.113 X-Spam-Level: X-Archive-Number: 200603/456 X-Sequence-Number: 17893 "Jim C. Nasby" writes: > 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. Well, lemme put it this way: I'm not prepared to require that PG be deterministic at the physical level. One obvious source of non-determinancy is the FSM, which is likely to hand out different free space to different transactions depending on what else is going on at the same time. There are others, such as deliberately random tie-breaking during btree index insertion. regards, tom lane