Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZB2K4-0006hV-QK for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jul 2015 14:52:12 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZB2K2-0007wv-Fh for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jul 2015 14:52:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZB2K0-0007uQ-SZ for pgsql-hackers@postgresql.org; Fri, 03 Jul 2015 14:52:08 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZB2Jx-0004Yw-Nd for pgsql-hackers@postgresql.org; Fri, 03 Jul 2015 14:52:08 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id t63Eq0ih028321; Fri, 3 Jul 2015 10:52:00 -0400 From: Tom Lane To: Fujii Masao cc: Martijn van Oosterhout , Andres Freund , PostgreSQL-development Subject: Re: WAL logging problem in 9.4.3? In-reply-to: References: <20150702220524.GA9392@svana.org> <20150702222102.GG30708@awork2.anarazel.de> <20150703052048.GA20285@svana.org> <20150703060137.GB20285@svana.org> Comments: In-reply-to Fujii Masao message dated "Fri, 03 Jul 2015 23:44:10 +0900" Date: Fri, 03 Jul 2015 10:52:00 -0400 Message-ID: <28320.1435935120@sss.pgh.pa.us> X-Pg-Spam-Score: -2.5 (--) 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 Fujii Masao writes: > The optimization of TRUNCATE opereation that we can use when > CREATE TABLE and TRUNCATE are executed in the same transaction block > seems to cause the problem. In this case, only index file truncation is > logged, and index creation in btbuild() is not logged because wal_level > is minimal. Then at the subsequent crash recovery, index file is truncated > to 0 byte... Very simple fix is to log an index creation in that case, > but not sure if that's ok to do.. > In 9.2 or before, this problem doesn't occur because no such error is thrown > even if an index file size is zero. But in 9.3 or later, since the planner > tries to read a meta page of an index to get the height of the btree tree, > an empty index file causes such error. The planner was changed that way by > commit 31f38f28, and the problem seems to be an oversight of that commit. What? You want to blame the planner for failing because the index was left corrupt by broken WAL replay? A failure would occur anyway at execution. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers