Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l1d2n-0006CK-AO for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Jan 2021 22:30:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l1d2l-00030y-V6 for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Jan 2021 22:30:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l1d2l-00030q-2x for pgsql-hackers@lists.postgresql.org; Mon, 18 Jan 2021 22:30:39 +0000 Received: from [66.111.4.29] (helo=out5-smtp.messagingengine.com) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l1d2g-0006hk-Sn for pgsql-hackers@lists.postgresql.org; Mon, 18 Jan 2021 22:30:38 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 509965C0231; Mon, 18 Jan 2021 17:30:23 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 18 Jan 2021 17:30:23 -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:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=K0SOJowXPXXe1qwP76pPy3v12feN/u+qO+hjuHnitjE=; b=QAVDcfd1 nxZcgcqcQZRTHznEpahTcaMyf4b4TPMVs+3VU0YHnmPj/QerThdo0T+ZmvewbKWK j3CJFX1zwtQ2N3uMCtNfeQvr8D2O41A8KcmN6rkKomSHxxuNofRqjQGI0AzVET5q PkQjMPCM3Ld8JzaiGLApgnZtCOyRW6md+LfmaAGXQe7OjKotykHSyRQgyzgb//7o r50z7DHQYuqrIAmUg3d2yuFgvqXwFuP6pGMKh8hanDV0zet8TMSNTxLammqz5wo+ v5PPuyhgYc3OoiIr4lnOgFEbL3p0wcA96nLOeooCMw+pLsOoVcIM0QTwuSdDoOeI Q0V9aG9ww3eCGQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtdekgdduieegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjfgesthekredttderudenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepueffhfejieeuueffgedvudekgeeltdeviedvieeufeei ieevgfetheeufeethedvnecukfhppeduledtrdelhedrudelrddujeejnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegr lhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 8A2421080063; Mon, 18 Jan 2021 17:30:22 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id C39B02A092A; Mon, 18 Jan 2021 19:30:19 -0300 (-03) Date: Mon, 18 Jan 2021 19:30:19 -0300 From: Alvaro Herrera To: Tom Lane Cc: Michael Paquier , pgsql-hackers@lists.postgresql.org Subject: Re: Odd, intermittent failure in contrib/pageinspect Message-ID: <20210118223019.GA2579@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <413923.1611006484@sss.pgh.pa.us> User-Agent: Mutt/1.10.1 (2018-07-13) X-Host-Lookup-Failed: Reverse DNS lookup failed for 66.111.4.29 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2021-Jan-18, Tom Lane wrote: > Searching the buildfarm logs turned up exactly one previous occurrence, > also on whelk [2]. So I'm not sure what to make of it. Could the > immediately preceding VACUUM FREEZE command have silently skipped this > page for some reason? That'd be a bug I should think. Hmm, doesn't vacuum skip pages when they are pinned? I don't think VACUUM FREEZE would be treated especially -- only "aggressive" wraparound would be an exception, IIRC. This would reflect in the relfrozenxid for the table after vacuum, but I'm not sure if there's a decent way to make the regression tests reflect that. > Also, not really a bug, but why is this test script running exactly > the same query twice in a row? If that's of value, and not just a > copy-and-paste error, the comments sure don't explain why. But what > it looks like is that these queries were different when first added, > and then 58b4cb30a5b made them the same when it probably should have > removed one. Agreed. -- Álvaro Herrera 39°49'30"S 73°17'W