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  (Bruce Momjian <bruce@momjian.us>)
Re: BUG #10911: pg_upgrade appears to lose the transaction id epoch  (Greg Stark <stark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: "Burgess, Freddie"
Дата:
Сообщение: Re: Postgresql 9.3.4 Streaming Replication Standby invalid Page block
Следующее
От: Tom Lane
Дата:
Сообщение: Re: LEFT JOINs not optimized away when not needed