Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZB4MK-0003vH-1P for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jul 2015 17:02:40 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZB4MJ-0004gq-C1 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jul 2015 17:02:39 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZB4MH-0004fs-Dp for pgsql-hackers@postgresql.org; Fri, 03 Jul 2015 17:02:37 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by makus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1ZB4ME-0005Fk-LC for pgsql-hackers@postgresql.org; Fri, 03 Jul 2015 17:02:36 +0000 Received: by mail.anarazel.de (Postfix, from userid 108) id F0CCA860003; Fri, 3 Jul 2015 19:02:32 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail X-Spam-Level: X-Spam-Status: No, score=-6.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from anarazel.de (p5DDC66C2.dip0.t-ipconnect.de [93.220.102.194]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id ECE9E860001; Fri, 3 Jul 2015 19:02:29 +0200 (CEST) Received: by anarazel.de (Postfix, from userid 1000) id 841AB102215; Fri, 3 Jul 2015 19:02:29 +0200 (CEST) Date: Fri, 3 Jul 2015 19:02:29 +0200 From: Andres Freund To: Fujii Masao Cc: Tom Lane , Martijn van Oosterhout , PostgreSQL-development Subject: Re: WAL logging problem in 9.4.3? Message-ID: <20150703170229.GJ3291@awork2.anarazel.de> References: <20150702220524.GA9392@svana.org> <20150702222102.GG30708@awork2.anarazel.de> <20150703052048.GA20285@svana.org> <20150703060137.GB20285@svana.org> <28320.1435935120@sss.pgh.pa.us> <20150703164931.GI3291@awork2.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150703164931.GI3291@awork2.anarazel.de> X-Pg-Spam-Score: -4.8 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 2015-07-03 18:49:31 +0200, Andres Freund wrote: > But the more interesting question is why that's not hhappening > today. RelationTruncateIndexes() does call the index_build() which > should end up WAL logging the index creation. So that's because there's an XLogIsNeeded() preventing it. Maybe I'm just daft right now (35C outside, 32 inside, so ...), but I'm right now missing how the whole "skip wal logging if relation has just been truncated" optimization can ever actually be crashsafe unless we use a new relfilenode (which we don't!). Sure, we do an heap_sync() at the the end of the transaction. That's nice and all. But it doesn't help if we crash and re-start WAL apply from a checkpoint before the table was created. Because that'll replay the truncation. That's much worse than just the indexes - the rows added by a COPY without WAL logging will also be truncated away, no? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers