其中一个我从未远离PostgreSQL的原因是，我总是发现PostgreSQL能够解决各种有趣的问题。但实话说，有时我觉得有些功能其实是在寻找问题的解决方案。例如，导出事务快照。
pg的事务快照导出功能最初是在9.2版本开始支持的，它允许多个事务去共享已获取的当前相同数据库状态的一个一致性视图。当时我不确定我该如何使用它，直到pg9.3版本的发布，pg_dump中引入了多线程的下载，呈现出了一个真实的用例。
下面是一个简单的例子，让我们通过创建两个包含大量数据的表开始：
表一如下：
begin;
create table t1(
c1 serial primary key,
c2 text default lpad(’’,500,md5(random()::text)),
c3 timestamp default clock_timestamp()
);
表二如下：
List of relations
Schema | Name | Type | Owner | Size | Description
--------+------+-------+----------+---------+-------------
public | t1 | table | postgres | 2791 MB |
public | t2 | table | postgres | 2791 MB |
提示：改变generate_series函数中的参数能够填充最适合你的硬件功能的表。
逻辑转储的传统调用是使用单个CPU/线程来一次归档一个表。CLI time 生成定时统计信息，使用“compressed”格式来返回执行转储所需的时间：
# execution time: 60 seconds
time pg_dump -Fc db01 > db01.db
另一种生成转储的调用使用”directory“格式来返回执行转储所需的时间：
# execution time: 52 seconds
time pg_dump -Fd db01 -f db01_dirA
执行过程使用单个CPU的特性就说到这。现在我们来看看建立多个连接来生成转储的‘-j’和‘jobs’切换的执行时间：
# execution time: 31 seconds
time pg_dump -Fd db01 -f db01_dirB -j 2
注意在后台运行的进程的数量。其中第三个连接是一个领导进程，它可以协调两个工作进程：
$: ps aux | grep -v grep | grep pg_dump
如果没有同步快照功能，将不能保证不同进程作业在每个连接中找到相同的数据，这可能会导致备份的不一致。
需要记住的一个重要的警告是pg_dump的jobs切换只适用于”directory“格式。尝试使用作业来对单个数据库进行转储将会失败：
pg_dump -Fc db01 -j 2 > db01.db
有关于使用jobs切换的其他注意事项，在PostgreSQL文档中有完整的描述。
现在我们已经展示完了它如何使用pg_dump去工作，但是我们能更进步一步吗？…当然了！
我们能够使用快照同步函数pg_export_snapshot()来复制行为。
继续使用前面两个已创建的表，我们来创建另外一个场景。让我们看看下表中的每一个步骤：
-
步骤1: 三个psql会话登录，并且先后与表t1和t2进行交互。
-
步骤2：会话1每5秒在表中插入一次数据。会话2与会话3查看数据的方式不同，请注意会话3中查询的三秒钟延迟，因此在同一时间查看同一数据集是有问题的。
-
步骤3：会话1继续更新表 t1、 t2，但是现在会话2和3都正在使用相同的快照会话。
-
步骤4：当会话1继续更新表t1、t2，会话2和会话3能看到相同的数据集，即它们是同步的。
-
步骤5：会话2和会话3同时在主动地复制数据，而不用担心不一致。
-
步骤6：COPY完成后，让我们通过提交事务来完成。
现在你就学会了这个巧妙的小技巧——导出快照！当然，除了以多线程的方式复制表之外，你还可以做更多的事情，但希望这篇小小的文章能让你在使用 Postgres 的时候有更多的机会来简化你的生活。
原文标题：Working With Snapshots in PostgreSQL
原文作者：Robert Bernier
原文地址：https://www.percona.com/blog/working-with-snapshots-in-postgresql/