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 1pMDVo-0000k2-Hg for pgsql-bugs@arkaria.postgresql.org; Sun, 29 Jan 2023 19:38:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pMDVm-0003Pa-47 for pgsql-bugs@arkaria.postgresql.org; Sun, 29 Jan 2023 19:38:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pMDVl-0003PR-3f for pgsql-bugs@lists.postgresql.org; Sun, 29 Jan 2023 19:38:45 +0000 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pMDVd-0000qT-SH for pgsql-bugs@lists.postgresql.org; Sun, 29 Jan 2023 19:38:44 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 6861632003F4; Sun, 29 Jan 2023 14:38:34 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 29 Jan 2023 14:38:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1675021113; x=1675107513; bh=H G+UExZ/M5KFKcoEPhjEtSGC9klbAoN6n2b+RAQGnaE=; b=RkLtNN2eKNwdQtWXw xSjGJQw9T1qadZACRcS5cK3qqZo0d6tERjPKkUW2Q75rY/40+S1jYXKW5mLwqZgZ PEoIJtV7mEsOp9U0AodiPTG3mor3v7V+Dvq+2gn0M08QKkFi7OWEkV3nJGAmt55T afmayPqONTlYWwRWHOy9xXxTI8wBrrrKV4wlHdEYZGr6Z21qcqSkspTsHiTESY17 G6FZ3XuXQNR1SDvXyrnUVd5SrphsQJfiMS2IbPJ2HACmB9TRpwxtAwiNSifubNiC N+MLRVRhD21fnLm1GfYFTtuiWKik0hnuU6UbbiaQo75ECOU9izle416BIRujW9Jk yOynQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeftddguddvlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhv rghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorh hgqeenucggtffrrghtthgvrhhnpedvkedtffduffdtffffheffhfejjefhgfeiueeukeej keffgfdufffhudffffeuveenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghl vhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 29 Jan 2023 14:38:33 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id D4D6299; Sun, 29 Jan 2023 20:24:21 +0100 (CET) Date: Sun, 29 Jan 2023 20:24:21 +0100 From: Alvaro Herrera To: Masahiko Sawada Cc: a.kozhemyakin@postgrespro.ru, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17741: vacuum process hangs after pg_surgery manipulations Message-ID: <20230129192421.pox3vbwqfscacdiu@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2023-Jan-18, Masahiko Sawada wrote: > While this is completely true and I agree, can we improve this > situation somewhat so that it ends up with an error instead of getting > hanged? Well, I don't know. I think in this case we would have to look at a patch that claimed to change the behavior, so that we can determine whether it's likely to break something else. > In this case, the tuple with a = 1, the root of the HOT chain, was > killed, and the tuple with a = 2 was heap-only tuple and HOT-updated. > In heap_page_prune(), we normally can prune the tuple with a = 2 as > part of pruning its chain, but since the root tuple was already killed > we could not prune this tuple. Then, we ended up retrying > heap_page_prune() since we saw as if the tuple became dead since > heap_page_prune() looked. My intuition for attacking this, is that we should definitely strive to change the behavior if the pattern of corruption is something that is seen to appear with some frequency. If it only happens because somebody was careless while running pg_surgery, then let's just leave it to her to complete the surgery. But if some unknown server bug causes it and we have a lot of people with vacuum hanging because of it, then I agree with might want to look for alternatives. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/