Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZB7Eu-00032F-MC for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jul 2015 20:07:12 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZB7Et-0000Fh-ST for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jul 2015 20:07:11 +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 1ZB7DC-0007FO-0O for pgsql-hackers@postgresql.org; Fri, 03 Jul 2015 20:05:26 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZB7D8-0000S4-UP for pgsql-hackers@postgresql.org; Fri, 03 Jul 2015 20:05:24 +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 t63K5HrD015206; Fri, 3 Jul 2015 16:05:17 -0400 From: Tom Lane To: Martijn van Oosterhout cc: Andres Freund , Fujii Masao , PostgreSQL-development Subject: Re: WAL logging problem in 9.4.3? In-reply-to: <20150703195736.GB2841@svana.org> References: <20150702222102.GG30708@awork2.anarazel.de> <20150703052048.GA20285@svana.org> <20150703060137.GB20285@svana.org> <28320.1435935120@sss.pgh.pa.us> <10146.1435942436@sss.pgh.pa.us> <20150703171426.GA2841@svana.org> <20150703172121.GL3291@awork2.anarazel.de> <20150703195736.GB2841@svana.org> Comments: In-reply-to Martijn van Oosterhout message dated "Fri, 03 Jul 2015 21:57:36 +0200" Date: Fri, 03 Jul 2015 16:05:17 -0400 Message-ID: <15205.1435953917@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 Martijn van Oosterhout writes: > With inserts the WAL records look as follows (relfilenodes changed): > ... > And amazingly, the database cluster successfuly recovers and there's no > error now. So the problem is *only* because there is no data in the > table at commit time. Which indicates that it's the 'newroot" record > that saves the day normally. And it's apparently generated by the > first insert. Yeah, because the correct "empty" state of a btree index is to have a metapage but no root page, so the first insert forces creation of a root page. And, by chance, btree_xlog_newroot restores the metapage from scratch, so this works even if the metapage had been missing or corrupt. However, things would still break if the first access to the index was a read attempt rather than an insert. 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