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 1pWjPc-0003j0-Ut for pgsql-bugs@arkaria.postgresql.org; Mon, 27 Feb 2023 19:43:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pWjPa-0002gp-QP for pgsql-bugs@arkaria.postgresql.org; Mon, 27 Feb 2023 19:43:50 +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 1pWjPa-0002ge-Hw for pgsql-bugs@lists.postgresql.org; Mon, 27 Feb 2023 19:43:50 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pWjPY-0004NM-5z for pgsql-bugs@lists.postgresql.org; Mon, 27 Feb 2023 19:43:49 +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 31RJhjIl409157; Mon, 27 Feb 2023 14:43:45 -0500 From: Tom Lane To: Cherio cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17810: Update from 13.09 to 13.10 breaks SQLs with VACUUM In-reply-to: References: <17810-8eb7b4e1b7a68e1a@postgresql.org> <371962.1677515656@sss.pgh.pa.us> <391334.1677520801@sss.pgh.pa.us> <392516.1677521462@sss.pgh.pa.us> Comments: In-reply-to Cherio message dated "Mon, 27 Feb 2023 13:41:56 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <409155.1677527025.1@sss.pgh.pa.us> Date: Mon, 27 Feb 2023 14:43:45 -0500 Message-ID: <409156.1677527025@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Cherio writes: > You are right. My mental model of the change is a speculation, but this is > only because the specifics of the change are not clarified anywhere. The problem is that statements that aren't allowed to execute in a transaction block (usually because they need an immediate commit) weren't checking that properly in the context of pipelined queries. This should never have been allowed, but we weren't enforcing that properly. The net effect in some cases is that such commands unexpectedly committed the effects of prior commands in the pipeline, and in other cases that a rollback occurring later in the pipeline would leave you with corrupted on-disk state. We judged that to be a bad enough bug that the fix should be backpatched. The original fix for that went in six months ago (13.8 et al) but we later discovered that there was still a hole in it. The fact that the 13.10 release notes only mention ANALYZE is a result of my inadequate summarization of the commit log entry :-(. > BTW, why ANALYZE? ANALYZE is a slightly different case. It can work inside a transaction block or not, but it has two different strategies depending on that: one uses internal commits and the other doesn't. It was applying the wrong one in this context, which again had the effect of prematurely committing previous commands in the pipeline. > Are VACUUM and ANALYZE the only commands that must be executed > separately? There's a couple dozen such commands --- easiest way to find them is to grep the source code for PreventInTransactionBlock calls. I believe "can't run inside a transaction block" is mentioned in all their manual pages, but we don't have a central list. regards, tom lane