Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iXixC-000142-SK for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Nov 2019 09:40:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iXixB-0007zp-EM for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Nov 2019 09:40:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iXixA-0007yp-8M for pgsql-hackers@lists.postgresql.org; Thu, 21 Nov 2019 09:40:45 +0000 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iXix6-0001mb-Ty for pgsql-hackers@postgresql.org; Thu, 21 Nov 2019 09:40:42 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id E6CF7857; Thu, 21 Nov 2019 04:40:38 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 21 Nov 2019 04:40:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=D36Jz7oGdf60HSR/vpKXkyoqxNxKwGMPk0qdX4bMz +o=; b=h/81Tf3gxV5EREvUfiQmQPzlVest/WgVKzJkcoyb6G7BFXKoVzh1r2gdg 8s8qhbUOMoyNICCPFzhbhwEljjPkgX3szyV6rA+e7KF7f0ARRVXpM4Iz1gXVE5a+ OHhfghOajCuUJNddoslfZI21PPnPi2OzmyG4EZ9FXnrkrAK6V9K0B/UmYAU/qOOE iDYsaLLwWimIPceA3DhixHPjbwXqxztuYk7x7C7Nsmj3x2p6Ba4Uc7M2XU/DMoSM VA8Is5SZ769DbugbP3ddDObNGObSVrkqdSo6om2uCiI2Qkk6fzb5RVjA8iEC9FDN uwNxH6QbWCBpa5MMDac8vtDZazYOw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehvddgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvght vghrucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvdhnug hquhgrughrrghnthdrtghomheqnecuffhomhgrihhnpedvnhguqhhurggurhgrnhhtrdgt ohhmnecukfhppeelfedrvdegvddrudegjedrjeelnecurfgrrhgrmhepmhgrihhlfhhroh hmpehpvghtvghrrdgvihhsvghnthhrrghuthesvdhnughquhgrughrrghnthdrtghomhen ucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from april.pezone.net (p5df2934f.dip0.t-ipconnect.de [93.242.147.79]) by mail.messagingengine.com (Postfix) with ESMTPA id A19FF3060069; Thu, 21 Nov 2019 04:40:37 -0500 (EST) Subject: Re: fix "Success" error messages To: TAKATSUKA Haruka , pgsql-hackers References: <5de61b6b-8be9-7771-0048-860328efe027@2ndquadrant.com> <20190618161319.GA5285@f01898859afd.ant.amazon.com> <20190619025155.GD17450@paquier.xyz> <36d38542-63e9-b73c-09fe-bd5e32e06066@2ndquadrant.com> <20190827062726.GF7422@paquier.xyz> <9cc51628-163c-2cc1-c9a7-cd03d1ed89ef@2ndquadrant.com> <20190927155239.GB31412@momjian.us> <20191121104257.a3010b3ec22f83e498147f74@sraoss.co.jp> Cc: Michael Paquier From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <5457fd8b-67e1-d399-b4d6-075776fed71a@2ndquadrant.com> Date: Thu, 21 Nov 2019 10:40:36 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20191121104257.a3010b3ec22f83e498147f74@sraoss.co.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-11-21 02:42, TAKATSUKA Haruka wrote: > FATAL: could not access status of transaction .. > DETAIL: Could not read from file (pg_clog/.... or pg_xact/....) ...: Success. > > This error has caused the server to fail to start with recovery. > I got a report that it happend repeatedly at the newly generated > standby cluster. I gave them advice to comfirm the low level server > environment. > > However, in addition to improving the message, should we retry to read > the rest of the data in the case reading too few bytes? > What about a limited number of retries instead of a complete loop? If we thought that would help, there are probably hundreds or more other places where we read files that would need to be fixed up in the same way. That doesn't seem reasonable. Also, it is my understanding that short reads can in practice only happen if the underlying storage is having a serious problem, so retrying wouldn't actually help much. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services