Re: Persistent changes in rolled-back transactions

From: Wael Khobalatte <wael(at)vendr(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Wells Oliver <wells(dot)oliver(at)gmail(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Persistent changes in rolled-back transactions
Date: 2022-11-10 01:40:12
Message-ID: CAJZ8yobSeSs8b28jzH5P4=OGvntPNxPyu_PsNWKm4De2E_WTjg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

> 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). As David mention I also thought it was not
transactional at all, but it seems it is in recent version or I am seeing
ghosts. Regardless, it's definitely fits the description of what you are
trying to be aware of when it comes to transactional behavior.

Consider starting a transaction in REPEATABLE READ, do a "begin", then
nothing (because if you select you block the upcoming truncate). In a
different session, do the truncation, commit it. Back to the REPEATABLE
READ transaction, still open, you select, the data is gone. Therefore
"persisted changes" is true.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Erik Wienhold 2022-11-10 02:39:20 Re: Allowing users to create objects in version controlled schema
Previous Message David G. Johnston 2022-11-10 01:23:35 Re: Persistent changes in rolled-back transactions