我有一个非常大的数百万行事务，我最终需要杀死它。该事务扫描了大量的行，如果满足某些条件，则在新表中创建新行。这是在一个提交块中，在我杀死进程之前没有完成-杀死进程并重新启动服务器会有什么影响吗？我甚至没有在数据库中看到表（大概是因为提交从未发生过）。我可以立即尝试再次进行迁移吗？
krcsximq1#
答案取决于你如何“杀死”交易。
pg_cancel_backend
pg_terminate_backend
您在会话中创建的任何表都将消失。如果您修改了预先存在的表中的行，则新行将是“死”的，autovacuum将删除它们。在最坏的情况下，您将在某些表中出现一些膨胀，这些表将被下一次尝试事务时重用。
kill
kill -9
在崩溃恢复后，您的数据库将保持一致，但可能会留下一些文件（属于新创建的表）。这些孤儿占用空间并且永远不会删除，唯一安全的方法是清除浪费的空间，将数据库转储并将其还原到新的数据库集群。
eeq64g8w2#
从理论上讲，是的。您应该可以继续尝试。这可能意味着一些清理尚未执行，因此有一些部分表浮动，占用内存，但不会影响数据质量。
2条答案
按热度按时间krcsximq1#
答案取决于你如何“杀死”交易。
pg_cancel_backend或pg_terminate_backend取消查询，事务将正常回滚。您在会话中创建的任何表都将消失。
如果您修改了预先存在的表中的行，则新行将是“死”的，autovacuum将删除它们。
在最坏的情况下，您将在某些表中出现一些膨胀，这些表将被下一次尝试事务时重用。
kill终止会话的后端进程，则一切正常。kill -9终止会话的后端进程，PostgreSQL将进入崩溃恢复。在崩溃恢复后，您的数据库将保持一致，但可能会留下一些文件（属于新创建的表）。这些孤儿占用空间并且永远不会删除，唯一安全的方法是清除浪费的空间，将数据库转储并将其还原到新的数据库集群。
eeq64g8w2#
从理论上讲，是的。您应该可以继续尝试。这可能意味着一些清理尚未执行，因此有一些部分表浮动，占用内存，但不会影响数据质量。