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 1osySv-000478-6p for pgsql-admin@arkaria.postgresql.org; Thu, 10 Nov 2022 03:42:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1osySs-0000LB-Gx for pgsql-admin@arkaria.postgresql.org; Thu, 10 Nov 2022 03:42:54 +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 1osySr-0000L0-UX for pgsql-admin@lists.postgresql.org; Thu, 10 Nov 2022 03:42:53 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1osySn-0005y2-OY for pgsql-admin@postgresql.org; Thu, 10 Nov 2022 03:42:51 +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 2AA3glJo078834; Wed, 9 Nov 2022 22:42:47 -0500 From: Tom Lane To: Wael Khobalatte cc: "David G. Johnston" , Wells Oliver , pgsql-admin Subject: Re: Persistent changes in rolled-back transactions In-reply-to: References: Comments: In-reply-to Wael Khobalatte message dated "Wed, 09 Nov 2022 20:40:12 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <78832.1668051767.1@sss.pgh.pa.us> Date: Wed, 09 Nov 2022 22:42:47 -0500 Message-ID: <78833.1668051767@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Wael Khobalatte writes: >> Why do you say truncate is non-transactional? Something simple proves >> that it's not? > Right, I meant 'non-transactional' in the sense that "persisted changes" as > you quoted them will also appear in the case of Truncate (MVCC-safety is > more correct here). Yeah, TRUNCATE will cause MVCC anomalies, in that data will disappear although it should still be visible to other transactions running with pre-TRUNCATE snapshots. Another thing TRUNCATE does that's not very kosher is to skip running ON DELETE triggers. If you don't like these things, use "DELETE FROM table" instead --- much slower, but no shortcuts. Sequences are the same sort of animal, in that they give up some transactional guarantees for performance reasons. For that matter, every transaction isolation level below full SERIALIZABLE represents a performance-vs-semantic-guarantees tradeoff. I can't offhand think of any more examples within Postgres, but I probably haven't thought long enough. regards, tom lane