From: | gregburek(at)heroku(dot)com |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | BUG #10911: pg_upgrade appears to lose the transaction id epoch |
Date: | 2014-07-08 21:17:05 |
Message-ID: | 20140708211705.2755.1240@wrigleys.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 10911
Logged by: Greg Burek
Email address: gregburek(at)heroku(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-07-08 21:40:00 | Re: LEFT JOINs not optimized away when not needed |
Previous Message | Burgess, Freddie | 2014-07-08 21:05:40 | Re: Postgresql 9.3.4 Streaming Replication Standby invalid Page block |