Christophe <xof@thebuild.com> writes:
> On Apr 21, 2009, at 1:20 PM, Tom Lane wrote:
>> They're both going to drop data that
>> might conceivably be visible in the snapshot of some concurrent
>> transaction that hasn't yet touched the table (else it would have
>> lock)
>> but might wish to do so later.
> Unless I'm deeply misunderstanding something (always a possibility),
> DROP TABLE and TRUNCATE are not symmetrical in this regard. Once a
> transaction has issued a DROP TABLE, all other transactions that
> attempt to modify it are going to block on the first transaction's
> ACCESS EXCLUSIVE lock until it commits or aborts. In the case of
> TRUNCATE, the other transactions will see the table as being empty
> from the moment in the first transaction issues the TRUNCATE, and will
> see the rows reappear if the first transaction rolls back. Yes?
No. They both take exclusive lock. Oh, and they are both safe in
the sense that the data is still there if the calling transaction
fails or rolls back. Perhaps that was what you meant by "transactional
safety"? I was thinking of MVCC semantics, which is a different issue.
regards, tom lane
