Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bn95j-0007cC-Kt for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Sep 2016 18:51:27 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bn95j-0007nL-1m for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Sep 2016 18:51:27 +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_2) (envelope-from ) id 1bn95h-0007mk-NR for pgsql-hackers@postgresql.org; Thu, 22 Sep 2016 18:51:25 +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_2) (envelope-from ) id 1bn95X-0008JK-Ta for pgsql-hackers@postgresql.org; Thu, 22 Sep 2016 18:51: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 u8MIp6OG008963; Thu, 22 Sep 2016 14:51:06 -0400 From: Tom Lane To: Robert Haas cc: Simon Riggs , Amit Kapila , Antonin Houska , pgsql-hackers Subject: Re: Possibly too stringent Assert() in b-tree code In-reply-to: References: <2628.1474272158@localhost> Comments: In-reply-to Robert Haas message dated "Mon, 19 Sep 2016 08:41:25 -0400" Date: Thu, 22 Sep 2016 14:51:06 -0400 Message-ID: <8962.1474570266@sss.pgh.pa.us> X-Pg-Spam-Score: -5.0 (-----) 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 Robert Haas writes: > On Mon, Sep 19, 2016 at 7:07 AM, Amit Kapila wrote: >> I think you have a valid point. It seems we don't need to write WAL >> for reuse page (aka don't call _bt_log_reuse_page()), if the page is >> new, as the only purpose of that log is to handle conflict based on >> transaction id stored in special area which will be anyway zero. > +1. This is clearly an oversight in Simon's patch fafa374f2, which introduced this code without any consideration for the possibility that the page doesn't have a valid special area. We could prevent the crash by doing nothing if PageIsNew, a la if (_bt_page_recyclable(page)) { /* * If we are generating WAL for Hot Standby then create a * WAL record that will allow us to conflict with queries * running on standby. */ - if (XLogStandbyInfoActive() && RelationNeedsWAL(rel)) + if (XLogStandbyInfoActive() && RelationNeedsWAL(rel) && + !PageIsNew(page)) { BTPageOpaque opaque = (BTPageOpaque) PageGetSpecialPointer(page); _bt_log_reuse_page(rel, blkno, opaque->btpo.xact); } /* Okay to use page. Re-initialize and return it */ but I'm not very clear on whether this is a safe fix, mainly because I don't understand what the reuse WAL record really accomplishes. Maybe we need to instead generate a reuse record with some special transaction ID indicating worst-case assumptions? 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