Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drsDv-0003Q8-04 for pgsql-bugs@arkaria.postgresql.org; Tue, 12 Sep 2017 20:55:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1drsDu-0008T4-Cf for pgsql-bugs@arkaria.postgresql.org; Tue, 12 Sep 2017 20:55:58 +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 1drsDB-0007Bo-MO for pgsql-bugs@postgresql.org; Tue, 12 Sep 2017 20:55:13 +0000 Received: from smtp-fw-6002.amazon.com ([52.95.49.90]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1drsD8-0002ko-EN for pgsql-bugs@postgresql.org; Tue, 12 Sep 2017 20:55:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1505249710; x=1536785710; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9dN6DC1PuGACbYKDwMGLLtfvffOb2scpHdgfXV6iXpM=; b=TKJsKESHwb7aVIDwxCfg58YiSQBX7a3eIwEoqYNUQoMg3Wus5Sbq/W3H 4vJ/faIHS+RLkS+hfc8S2peOY9/3VDjHlfCTA0GeGgQLpa3OpfCmoaWtk Z1LBno2fHvX7RN9Wyd3MVbSwzNw9dz4WdQINr+K8NSXCQyDrCukDBE8Wk 8=; X-IronPort-AV: E=Sophos;i="5.42,384,1500940800"; d="scan'208";a="305134568" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2a-69849ee2.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Sep 2017 20:55:01 +0000 Received: from EX13MTAUWB001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2a-69849ee2.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id v8CKswQY019996 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Sep 2017 20:54:58 GMT Received: from EX13D11UWB001.ant.amazon.com (10.43.161.53) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 12 Sep 2017 20:54:58 +0000 Received: from EX13D04UWA001.ant.amazon.com (10.43.160.47) by EX13D11UWB001.ant.amazon.com (10.43.161.53) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 12 Sep 2017 20:54:58 +0000 Received: from EX13D04UWA001.ant.amazon.com ([10.43.160.47]) by EX13D04UWA001.ant.amazon.com ([10.43.160.47]) with mapi id 15.00.1104.000; Tue, 12 Sep 2017 20:54:58 +0000 From: "Wong, Yi Wen" To: Alvaro Herrera , Michael Paquier CC: Peter Geoghegan , "Wood, Dan" , "pgsql-bugs@postgresql.org" , Andres Freund Subject: Re: Old row version in hot chain become visible after a freeze Thread-Topic: [BUGS] Old row version in hot chain become visible after a freeze Thread-Index: AQHTJ3fzEH9T5bMCDUufad1KxDA7S6Kvvd+AgAEpfwCAAAoegIAAp59AgAAqJpA= Date: Tue, 12 Sep 2017 20:54:58 +0000 Message-ID: <1505249698051.58904@amazon.com> References: ,<20170912082203.gq5hutuveqlxpvuc@alvherre.pgsql>,<1505241452245.71279@amazon.com> In-Reply-To: <1505241452245.71279@amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.131] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-bugs Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org > > > I also tweaked lazy_record_dead_tuple to fail with ERROR if the tuple > > > cannot be recorded, as observed by Yi Wen. AFAICS that's not reachab= le > > > because of the way the array is allocated, so an elog(ERROR) is > > > sufficient. > > I agree the fail is rare (and probably doesn't happen in real cases, alth= ough the comment > does imply with a sufficiently low working_memory it might?). However, I'= d dispute that ERROR > is sufficient --PANIC is probably appropriate here because FREEZE is not = WAL-logged until > the end of the page; so we'd end up with unfrozen Xids hanging around wit= h an appropriately > timed crash. I wouldn't worry much about the PANIC tripping because like = you said, > this seems unreachable normally. >=20 > The errmsg should come with a errhint saying "Increase maintenance_work_m= em". On closer inspection, I misread the code. The freezes are collected instead= of executed, so a ERROR would suffice. We don't need to change it to PANIC. errhint comment remains. Yi Wen --=20 Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs