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?
