Wael Khobalatte <wael@xxxxxxxxx> 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
