在 Derby（一个用 Java 编写的嵌入式数据库，主要用于测试或原型设计）中，有可以在在线备份期间使用的“冻结”和“解冻”命令。“冻结”只会导致所有数据库访问阻塞，直到调用“解冻”。这对于使用外部程序进行备份很有用，如果外部程序比使用 Derby 的内部备份解决方案快得多，您可能会这样做。对于我的用例，我可以使用一些内置的文件系统实用程序几乎立即拍摄快照，因此它是一个恒定时间操作（不是O(length of DB files)）。
我正在将一个已经超过 Derby 的应用程序迁移到 PostgreSQL，我想知道那里是否有任何类似的东西可以用来停止所有连接。此外，我更愿意从我的应用程序内部知道我的序列化点是什么，这样我就不会陷入某种尴尬的状态，因此能够暂停/恢复所有其他访问对我来说真的很不错。
由于 PostgreSQL 有一个事务日志，我可以只拍摄快照而不“冻结”，但快照需要通过 PostgreSQL 的恢复机制运行才能使用它，因为否则存储在磁盘上的内容与我拉取的内容相同普通文件系统上的插件。这种解决方案并不理想。
编辑我了解到这pg_start_backup()很接近，但它不会导致传入事务阻塞，直到匹配调用pg_stop_backup()，迫使我做一个时间点恢复回到pg_start_backup()从文件系统快照返回的事务 id。不必真正关闭 PostgreSQL 来获得它会很好（也许有一个伪关闭命令可以保持连接打开？）。
没有与您想要的完全等价的东西。选项包括：
原子文件系统快照
如果您使用的是原子文件系统快照，则无需冻结数据库。如果你强制
CHECKPOINT第一次，它可能会使恢复更快一点，但仅此而已。当您拍摄文件系统快照并复制它，然后开始复制时，对于 PostgreSQL，它就好像它崩溃并开始备份一样。这很好，它是碰撞安全的，并且旨在以这种方式工作。这种方法只有在快照是原子的情况下才有效——它们都在同一个虚拟瞬间。您无法跨多个文件系统（至少在 Linux 上）获得原子快照，因此如果您的数据库被拆分为多个表空间或 WAL 位于堆的单独磁盘上，则您无法使用此方法。
pg_start_backup/pg_stop_backup如果你不能做一个原子快照，你可以启用 WAL 归档、运行
pg_start_backup、复制数据库、运行pg_stop_backup和捕获最后生成的 WAL 归档。它有点复杂，但它可以为您提供一致的备份，而无需停止写入，也不需要文件系统级别的原子快照。
pg_basebackup使用
pg_start_backupand的替代方法pg_stop_backup是pg_basebackup通过PostgreSQL复制协议使用--xlog-method=stream. 这只需要一个PostgreSQL 复制连接，不需要停止数据库，并且非常无缝。--xlog-method=stream仅在最近的版本中添加，并且pg_basebackup它本身是相当新的。pg_dump我最初没有提到它，因为您正在寻找外部工具，但总是有
pg_dump，它获取SERIALIZABLE数据库的快照并将其转储。数据库继续正常运行（它仍然可以接受写入），并且从您开始转储开始，转储在内部完全一致。写静止
停止所有传入事务不会停止 PostgreSQL 写入。它仍然
VACUUM与 autovacuum、要执行的检查点、要写入的统计信息等有关。在这一点上，Pg 中没有停止所有写入的功能。添加它可能会很好，但我不知道有人在做它。
一些文件系统，如 XFS，支持文件系统级别的写入冻结；这会导致所有写入阻塞，直到释放冻结。冻结所有文件系统然后复制所有文件系统是安全的。