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.92) (envelope-from ) id 1jH5Ya-0003kY-OW for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2020 12:54:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jH5YZ-0007ih-KO for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2020 12:54:51 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1jH5XG-0002a2-Re for pgsql-hackers@lists.postgresql.org; Wed, 25 Mar 2020 12:53:30 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jH5XD-0000gc-3G for pgsql-hackers@lists.postgresql.org; Wed, 25 Mar 2020 12:53:30 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 94E9A5C01A6; Wed, 25 Mar 2020 08:53:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 25 Mar 2020 08:53:25 -0400 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=fm2; bh=T5Hl7+bYtru8aoxS4Hks2/qrMH0slC+Xl91kMZcSk G0=; b=cEd6P6zF/zzqIWCsMZtExjRZ/ugLldV4jwYvffK5O2BqYouu+2sp5q/Hc zoyVEOEE8kEtFIgsZipwMdQw+Y8d1+5BtoMjEqMxHNh+rHuQtzpEP6TYSoNEqMNO Tfzm4oSXLf4VKnkfhOjvKw8CuRWDLNOT98dE8Lz9tX22fmfXzwXfBCkzt1OYjk7o D0TNvfSfXefOPMIZxnmnhPT8YWrp0ZmJpMspNc6CrpgXBhHnzq7CjXicQ3Go1aKZ Tvq3IbY17UTvDdNp6FE4HTJtJ3Z/t2YLbLzoyMGmufSzJzLkrnrelXfDNOTI4vz3 Nn4xMhca1IoIAfvNStbzW+qMjTBJA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehgedgvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhfhokffffgggjggtgfesth ejredttdefheenucfhrhhomheprfgvthgvrhcugfhishgvnhhtrhgruhhtuceophgvthgv rhdrvghishgvnhhtrhgruhhtsedvnhguqhhurggurhgrnhhtrdgtohhmqeenucffohhmrg hinhepvdhnughquhgrughrrghnthdrtghomhenucfkphepleefrddvgedvrddvudefrddv gedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepph gvthgvrhdrvghishgvnhhtrhgruhhtsedvnhguqhhurggurhgrnhhtrdgtohhm X-ME-Proxy: Received: from april.pezone.net (p5df2d5f1.dip0.t-ipconnect.de [93.242.213.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 67DAE306618B; Wed, 25 Mar 2020 08:53:24 -0400 (EDT) Subject: Re: Make mesage at end-of-recovery less scary. To: Kyotaro Horiguchi , andres@anarazel.de References: <20200305.160650.1027844943773682801.horikyota.ntt@gmail.com> <4a9fc5b1-34c8-46ec-9b71-d4763d70311d@2ndquadrant.com> <20200323194736.uijmupfle2ccvyah@alap3.anarazel.de> <20200324.105250.1584846618506385212.horikyota.ntt@gmail.com> Cc: michael@paquier.xyz, pgsql-hackers@lists.postgresql.org From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <613cc9dc-1721-eb73-70a5-ab5b4a7a5aee@2ndquadrant.com> Date: Wed, 25 Mar 2020 13:53:23 +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: <20200324.105250.1584846618506385212.horikyota.ntt@gmail.com> Content-Type: text/plain; charset=windows-1252; 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 2020-03-24 02:52, Kyotaro Horiguchi wrote: >> I don't find that very satisfying, but I can't come up with something >> that provides the current information, while being less scary than my >> suggestion? > The 0-length record is not an "invalid" state during recovery, so we > can add the message for the state as "record length is 0 at %X/%X". I > think if other states found there, it implies something wrong. > > LSN is redundantly shown but I'm not sure if it is better to remove it > from either of the two lines. > > | LOG: reached end of WAL at 0/3000850 on timeline 1 in pg_wal during crash recovery > | DETAIL: record length is 0 at 0/3000850 I'm not up to date on all these details, but my high-level idea would be some kind of hint associated with the existing error messages, like: HINT: This is to be expected if this is the end of the WAL. Otherwise, it could indicate corruption. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services