BUG #10911: pg_upgrade appears to lose the transaction id epoch

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

Responses

Browse pgsql-bugs by date

  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