SQL Server 的文档谈到了在崩溃恢复期间将已提交的事务应用于数据文件，有点像在执行即时检查点。这应该在撤消未提交的事务之前发生，而撤消未提交的事务必须发生才能完成恢复过程。
为什么它会立即将已提交的事务刷新到数据文件中，而不是只将脏数据加载到 RAM 缓存中（与崩溃前数据存储在缓存 + 日志中的方式相同），然后将其作为下一个检查点的一部分写出？这似乎会不必要地延长崩溃恢复时间。
我正在尝试将我们的 PostgreSQL 9.4 数据库从事务级别迁移READ COMMITTED到REPEATABLE READor 或SERIALIZABLE. 无论哪种情况，我都会遇到一组新的格式错误：
(for both)
ERROR: could not serialize access due to concurrent update
(just for SERIALIZABLE)
ERROR: could not serialize access due to read/write dependencies among transactions
在阅读了有关 SSI 的 wiki 页面和文档后，我彻底了解了可能导致这些错误的错误条件、如何处理它们，甚至是避免它们的最佳实践。
但是，我看不到任何方法可以确定导致它们从 PostgreSQL 可以提供的任何调试输出或任何调试信息中产生的数据依赖性。有没有办法从数据库中获取这些信息，或者通过在回滚时执行额外的查询，或者通过一些日志机制？
拥有这些信息将使我能够进行应用程序级别的更改（锁定、不同的查询等），从而消除一些数据竞争以避免过多的回滚。
在我的系统上，whoami返回Dan. 我initdb带着这个--username=PgUser论点跑。然后作为操作系统用户Dan，我pg_ctl start在新初始化的集群上运行，它给出了以下输出：
LOG: database system was shut down at 2013-06-13 00:54:33 UTC
LOG: autovacuum launcher started
LOG: database system is ready to accept connections
FATAL: role "Dan" does not exist
done
server started
服务器似乎已正常启动。我相信发生错误是因为它希望我以pg_ctl名为PgUser. 我想知道的是：
- 这种信念正确吗？
- 有没有办法将用户指定为
PgUser不使用su？我不希望创建一个新的操作系统用户，而是希望使用具有不同用户名的 PostgreSQL 用户（我正在做一些代码重构，使这更方便）。 - 我开始的实例是否因为我以操作系统用户身份启动而以某种方式瘫痪
Dan？
在 Derby（一个用 Java 编写的嵌入式数据库，主要用于测试或原型设计）中，有可以在在线备份期间使用的“冻结”和“解冻”命令。“冻结”只会导致所有数据库访问阻塞，直到调用“解冻”。这对于使用外部程序进行备份很有用，如果外部程序比使用 Derby 的内部备份解决方案快得多，您可能会这样做。对于我的用例，我可以使用一些内置的文件系统实用程序几乎立即拍摄快照，因此它是一个恒定时间操作（不是O(length of DB files)）。
我正在将一个已经超过 Derby 的应用程序迁移到 PostgreSQL，我想知道那里是否有任何类似的东西可以用来停止所有连接。此外，我更愿意从我的应用程序内部知道我的序列化点是什么，这样我就不会陷入某种尴尬的状态，因此能够暂停/恢复所有其他访问对我来说真的很不错。
由于 PostgreSQL 有一个事务日志，我可以只拍摄快照而不“冻结”，但快照需要通过 PostgreSQL 的恢复机制运行才能使用它，因为否则存储在磁盘上的内容与我拉取的内容相同普通文件系统上的插件。这种解决方案并不理想。
编辑我了解到这pg_start_backup()很接近，但它不会导致传入事务阻塞，直到匹配调用pg_stop_backup()，迫使我做一个时间点恢复回到pg_start_backup()从文件系统快照返回的事务 id。不必真正关闭 PostgreSQL 来获得它会很好（也许有一个伪关闭命令可以保持连接打开？）。