gpt4 book ai didi

postgresql - Postgres COPY FROM 永远

转载 作者:行者123 更新时间:2023-11-29 11:44:32 27 4
gpt4 key购买 nike

我有一个程序会或多或少地通过标准输入使用 COPY FROM 将大量数据复制到 Postgres 9 中。

这目前工作正常,但我正在缓冲数据 block ,然后分批运行 COPY FROM 操作。

我想知道,并且在环顾四周后找不到,是否只创建 COPY FROM 流并且在我的程序终止之前永远不关闭它对我来说是不是一个坏主意。例如,当我的程序正在运行并接受新数据时,我想打开一个 COPY FROM 并在其生命周期内持续流式传输该数据。

我正在寻找 Postgres 端的内部机制:

  • COPY FROM 操作是否在内部创建交易?
  • 相关:其他 session 是否可以立即访问我流式传输的数据?
  • Postgres 是否有任何内部机制会导致它无法工作(即某些内部状态会在不例行关闭 COPY FROM 流的情况下溢出)?

注意:我知道类似的考虑也适用于我正在使用的客户端驱动程序,但我假设(可能是错误的)客户端的选择不会改变我对 Postgres 端的要求东西的。如果可能的话,我想让这个问题特别关注 Postgres。

最佳答案

Does the COPY FROM operation create a transaction internally?

Postgres 中的每条 SQL 语句,包括 COPY FROM,都将成为较大事务的一部分,或者将自身包装在事务中。 ref :

PostgreSQL actually treats every SQL statement as being executed within a transaction. If you do not issue a BEGIN command, then each individual statement has an implicit BEGIN and (if successful) COMMIT wrapped around it. A group of statements surrounded by BEGIN and COMMIT is sometimes called a transaction block.

--

Related: Will the data I'm streaming be immediately accessible to other sessions?

不,未提交的数据永远不会对其他事务可见。在 SQL 术语中,这称为“脏读”,在 Postgres 中是不可能的 ref .

Does Postgres have any internal mechanics that would cause this to not work (i.e. some internal state that would overflow without routine closing of the COPY FROM stream)?

没有什么能直接阻止你这样做。但总的来说,将您的交易保持相对较短以与系统的其余部分合作被认为是一种很好的做法。如果您让 COPY FROM 语句闲置数小时,您将对 VACUUM 能够完成其工作产生影响 ref .

要考虑的另一个方面是锁定影响。如果您在表上建立了主键、唯一索引或其他约束(您应该这样做!),Postgres 将理解您正在COPY 中的行持有行级锁,直到它们被删除坚定的。假设您正在使用 unique_column='abc123' 连续COPYing,并且您让这个语句闲置了几个小时。如果其他人出现并试图COPYINSERT 也有unique_column='abc123' 的行,他将被阻止,直到您的COPY FROM 事务最终提交。这种行为可能会在整个系统中引起阻塞事务的链式 react ,并在最坏的情况下使您的数据库陷入停顿,尤其是当您要COPY进入的表被其他作者激烈争用时.

关于postgresql - Postgres COPY FROM 永远,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/47141329/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com