Amazon redshift 如何确保在被替换的表上执行同步DDL操作？

我有多个进程在不断刷新红移数据。他们启动一个事务，创建一个新表，将S3中的所有数据复制到新表中，然后删除旧表并将新表重命名为旧表

伪代码：

start transaction;
create table foo_temp;
copy into foo_temp from S3;
drop table foo;
rename table foo_temp to foo;
commit;

我用这种方式更新了几十个表。这很好，但我希望有多个进程执行这些表更新以达到冗余目的，并确保数据相当新鲜。不同的进程可以同时更新不同表的数据

除非一个进程尝试刷新另一个进程正在处理的表，否则它工作正常。在这种情况下，第二个进程会被第一个进程阻塞，直到它提交为止，当它提交时，第二个进程会收到错误：

错误：并发事务已删除表12345

有没有一种简单的方法可以保证只有一个进程正在刷新表，这样第二个进程就不会出现这种情况

---

我考虑为我的每个实际表创建一个特殊的锁表。该进程将在处理伴随的实表之前锁定特殊锁表。我认为这会起作用，但我希望避免为我的每个表创建一个特殊的锁表。

您需要保护读者不被删除，请通过以下方式执行此操作：

开始交易 将主表重命名为旧的主表 将tmp表重命名为主表 犯罪 放下旧的主桌

---

您考虑过了吗？不幸的是，这是Redshift不支持的事情之一：从RENAME开始，并允许读者查询它，直到过程结束，只有当前会话才能到达目标旧表。很有意思的是，如果drop table命令在commit命令之后或之前，那么这一点很重要？@AvivNoy答案与以下行有关：系统目录表PG和其他亚马逊红移系统表STL和STV在事务中未锁定；因此，DDL和TRUNCATE操作对数据库对象的更改在提交到任何并发事务时都是可见的。重命名和删除是AFAICT，不是事务的一部分，并且立即可见。提交后删除确保没有其他连接具有对表的未完成引用。 Conn #1 Conn #2 -------------- ------------------------------------------ > create table bar (id int,id2 int,id3 int); CREATE TABLE > begin; BEGIN > begin; BEGIN > alter table bar rename to bar2; ALTER TABLE > select * from bar; > create table bar (id int,id2 int,id3 int,id4 int); CREATE TABLE > commit; drop table bar2; COMMIT id | id2 | id3 ----+-----+----- (0 rows) > commit; COMMIT DROP TABLE