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 1tIteE-00HKZr-Ev for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Dec 2024 17:58:50 +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 1tIteB-001w2J-JS for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Dec 2024 17:58:48 +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 1tIteB-001w2B-9J for pgsql-hackers@lists.postgresql.org; Wed, 04 Dec 2024 17:58:48 +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 1tIte9-0013Iz-Fq for pgsql-hackers@postgresql.org; Wed, 04 Dec 2024 17:58:47 +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 4B4HwhMC2372480; Wed, 4 Dec 2024 12:58:43 -0500 From: Tom Lane To: Robert Haas cc: "pgsql-hackers@postgresql.org" Subject: Re: deferred writing of two-phase state files adds fragility In-reply-to: References: <2367443.1733332741@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Wed, 04 Dec 2024 12:44:05 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <2372478.1733335123.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Wed, 04 Dec 2024 12:58:43 -0500 Message-ID: <2372479.1733335123@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > On Wed, Dec 4, 2024 at 12:19 PM Tom Lane wrote: >> Could we fix it so ROLLBACK TRANSACTION removes the GID from the >> list of prepared xacts that need to be written out? Then we'd >> no longer have a pending requirement to read the broken WAL record. > That would be nice, but I'm not sure that it's possible. As currently > implemented, FinishPreparedTransaction() always reads the two-phase > state data either from the two-phase file or the WAL, whether it's > committing or rolling back. I'm not following. FinishPreparedTransaction is not what's preventing checkpoints or holding back the VACUUM horizon. What is doing that is the in-memory fake PGPROC representing the prepared transaction (I forget the exact terminology). I'm suggesting that we could have some way to nuke one of those without properly cleaning up the prepared xact. Maybe it'd need to be invoked via a different command than ROLLBACK TRANSACTION. regards, tom lane