Re: Persistent changes in rolled-back transactions

Wael Khobalatte <wael(at)vendr(dot)com> 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