BUG #10911: pg_upgrade appears to lose the transaction id epoch
От | gregburek@heroku.com |
---|---|
Тема | BUG #10911: pg_upgrade appears to lose the transaction id epoch |
Дата | |
Msg-id | 20140708211705.2755.1240@wrigleys.postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #10911: pg_upgrade appears to lose the transaction
id epoch
Re: BUG #10911: pg_upgrade appears to lose the transaction id epoch |
Список | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 10911 Logged by: Greg Burek Email address: gregburek@heroku.com PostgreSQL version: 9.0.17 Operating system: Ubuntu Linux Description: When upgrading a 9.0.17 db to 9.3.4 via pg_upgrade, the transaction ids appear to fall backward in time: >From before the upgrade: => SELECT txid_snapshot_xmax(txid_current_snapshot()); txid_snapshot_xmax -------------------- 66329538555 (1 row) After the upgrade: => SELECT txid_snapshot_xmax(txid_current_snapshot()); txid_snapshot_xmax -------------------- 1905029395 (1 row) Looking at pg_control before the upgrade: $ pg_controldata /database/ | grep -i nextxid Latest checkpoint's NextXID: 15/1905728256 After the upgrade: $ pg_controldata /database/ | grep -i nextxid Latest checkpoint's NextXID: 0/1905029398 This is an unexpected loss of the higher order bits when the upgrade is performed. Is it possible to preserve the epoch across the upgrade? thanks, Greg
В списке pgsql-bugs по дате отправления: