Re: Persistent changes in rolled-back transactions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Postgresql Home]     [Postgresql General]     [Postgresql Performance]     [Postgresql PHP]     [Postgresql Jobs]     [PHP Users]     [PHP Databases]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Yosemite Forum]

  Powered by Linux