Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tKgIP-00AAWX-OZ for pgsql-performance@arkaria.postgresql.org; Mon, 09 Dec 2024 16:07:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tKgIN-009rCm-5B for pgsql-performance@arkaria.postgresql.org; Mon, 09 Dec 2024 16:07:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tKgIM-009rCe-QK for pgsql-performance@lists.postgresql.org; Mon, 09 Dec 2024 16:07:40 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tKgIL-001uk9-AR for pgsql-performance@lists.postgresql.org; Mon, 09 Dec 2024 16:07:39 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 4B9G7ZHA3908774; Mon, 9 Dec 2024 11:07:35 -0500 From: Tom Lane To: Christophe Pettus cc: Lars Aksel Opsahl , "pgsql-performance@lists.postgresql.org" Subject: Re: PostgreSQL and a Catch-22 Issue related to dead rows In-reply-to: <5EE4CC0C-E624-4E82-A2E8-B2EBA44D3521@thebuild.com> References: <5EE4CC0C-E624-4E82-A2E8-B2EBA44D3521@thebuild.com> Comments: In-reply-to Christophe Pettus message dated "Mon, 09 Dec 2024 06:32:59 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3908772.1733760455.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 09 Dec 2024 11:07:35 -0500 Message-ID: <3908773.1733760455@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Christophe Pettus writes: >> On Dec 9, 2024, at 03:02, Lars Aksel Opsahl wrot= e: >> If there were a way to remove dead rows without requiring a commit from= totally unrelated jobs, it would be much easier. > (Strictly speaking, the rows you are describing are not "dead," in that = they are still visible to some transaction.) We do only very coarse-grained analysis of whether a row is "dead". In principle, if vacuum had access to all the live snapshots of all sessions, it could realize that a row really is dead even though it's later than the current global xmin horizon. But discovering that would be quite difficult and therefore expensive. Notably, sessions would have to expose far more of their snapshot state than they do today, and there would have to be interlocks to allow other sessions to inspect that state safely, and that'd probably put us into much the same sort of too-many-lock-conflicts problem that the OP has already. I don't think there's any free lunch here. Maybe there's some other compromise between amount-of-state-exposed versus dead-row-discoverability, but finding a better way would take a great deal of creative effort and testing. regards, tom lane