Postgres事务中的DROP TABLE行为

Question

假设我正在开发一个ETL,它定期从CSV中读取源数据并替换Postgres中的表(9.6).

这是一种方法:

BEGIN
DROP TABLE IF EXISTS table
CREATE TABLE table (...)
COPY table FROM STDIN (FORMAT csv, HEADER true)
CREATE INDEX ON table (...)
COMMIT

这是另一个:

BEGIN
CREATE TABLE table_temp (...)
COPY table_temp FROM STDIN (FORMAT csv, HEADER true)
CREATE INDEX ON table_temp (...)
DROP TABLE IF EXISTS table
ALTER TABLE table_temp RENAME TO table
COMMIT

我对以下内容是否正确？

• 第一个事务将锁定该DROP命令的表,因此并发SELECT查询将阻塞,直到事务完成.
• 第二个交易不会阻止SELECT查询,直到后COPY和CREATE INDEX光洁度.
• 这两个事务都是原子的:在任何一种情况下,如果我发出一个ROLLBACK而不是COMMIT,那么将使用所有原始数据和索引恢复该表.

此外,除了索引的名称,是否还有其他功能差异？

Answer 1

是的，您的所有三个假设都是正确的。

对于这两个事务，最终结果将是相同的，但是由第一个事务引起的阻塞将更长，并且取决于数据量和创建索引所花费的时间。第二个事务将需要一个非常简短的锁来重命名对象。