现在，我阅读了关于“Transaction ID Wraparound”的文档，但有一些我真的不明白，该文档是以下网址 http://www.postgresql.org/docs/9.0/static/routine-vacuuming .html#VACUUM-FOR-WRAPAROUND
23.1.4. 防止事务 ID 环绕失败
PostgreSQL 的 MVCC 事务语义依赖于能够比较事务 ID (XID) 编号：插入 XID 大于当前事务 XID 的行版本是“将来”的，不应对当前事务可见。但是由于事务 ID 的大小有限（32 位），一个长时间运行（超过 40 亿个事务）的集群将遭受事务 ID 环绕：XID 计数器环绕为零，并且突然之间的事务在过去似乎在未来——这意味着它们的输出变得不可见。简而言之，灾难性的数据丢失。（实际上，数据仍然存在，但是如果您无法获得它，那就太冷了。）为了避免这种情况，必须至少每 20 亿个事务一次对每个数据库中的每个表进行一次真空吸尘。
我不理解语句“将遭受交易 ID 环绕：XID 计数器环绕为零，突然之间过去的交易似乎在未来 - 这意味着它们的输出变得不可见”
有人可以解释一下吗？为什么在数据库遭受事务 ID 环绕之后，过去的事务会出现在未来？简而言之，我想知道在autovacuum事务ID回绕后PostgreSQL是否会出现“数据丢失”的情况？
对于我个人的观点，我们可以通过使用 txid_current() 函数来获取当前事务 ID，输出是 64 位的，不会被循环。所以我认为知道为 xmin 的元组的插入事务 ID 会比得到的 xid 更大通过 txid_current() 函数。除了您将在关闭 PostgreSQL 服务器后使用 pg_resetxlog reset reset transaction ID。我对吗 ？谢谢
我使用archive_command下面的文件来归档 WAL 文件。假设我已经接触过该文件archive_active。PostgreSQL 什么时候执行提供archive_command的归档 WAL 文件？
我知道我们可以使用该函数pg_switch_xlog()按需归档WAL，还有其他触发条件吗？
PostgreSQL 版本：9.3.0。
--postgresql.conf
archive_command = 'test ! -f /archive/pg93/archive_active || cp %p /archive/pg93/%f'
wal_level = hot_standby
archive_mode = on
--归档目录
[pg93@redhatB pg93]$ pwd
/archive/pg93
[pg93@redhatB pg93]$ ll
total 32M
-rw-------. 1 pg93 pg93 16M Oct 16 11:05 00000001000000000000007A
-rw-------. 1 pg93 pg93 16M Oct 16 11:07 00000001000000000000007B
-rw-rw-r--. 1 pg93 pg93 0 Oct 16 11:05 archive_active
最近开始学习pgbouncer，但是对参数有一些不明白的地方server_reset_query。
问题一：主要目的是server_reset_query什么？
问题2：pgbouncer的pool_mode有3种模式：session模式、transaction模式和statement模式。当 pool_mode 为 session 时，我们通常将
server_reset_query的值设置为 'DISCARD ALL'。当 pool_mode 为事务时，我们通常将 server_reset_query 的值设置为 ''?
我不知道这方面的细节，所以有人可以解释一下吗？
我们知道 WAL 文件位于$PGDATA/pg_xlog目录中，但我不知道 WAL 文件的含义，例如名为“0000000A00005283000000E0”的 WAL 文件，
我看到一些博客说 WAL 文件名尊重格式名称，该格式名称细分为 3 个由 8 个十六进制数字组成的序列，定义：
时间线 ID
区块ID
段 ID
但我仍然不明白这一点。任何人都可以解释这一点？
- 询问
francs=> select pg_current_xlog_location();
pg_current_xlog_location
--------------------------
5283/D9C2A320
(1 row)
francs=> select pg_xlogfile_name(pg_current_xlog_insert_location());
pg_xlogfile_name
--------------------------
0000000A00005283000000E0
postgresql ×4