pgsql: Reset btpo.xact following recovery of btree delete page.
Log Message:
-----------
Reset btpo.xact following recovery of btree delete page. Add btpo_xact
field into WAL record and reset it from there, rather than using
FrozenTransactionId which can lead to some corner case bugs.
Problem report and suggested route to a fix from Heikki, details by me.
Modified Files:
--------------
pgsql/src/backend/access/nbtree:
nbtpage.c (r1.120 -> r1.121)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtpage.c?r1=1.120&r2=1.121)
nbtxlog.c (r1.62 -> r1.63)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtxlog.c?r1=1.62&r2=1.63)
pgsql/src/include/access:
nbtree.h (r1.130 -> r1.131)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/nbtree.h?r1=1.130&r2=1.131)
sriggs@postgresql.org (Simon Riggs) writes:
Log Message:
-----------
Reset btpo.xact following recovery of btree delete page. Add btpo_xact
field into WAL record and reset it from there, rather than using
FrozenTransactionId which can lead to some corner case bugs.
Simon, you can't just whack WAL record contents around without a care.
This commit breaks on-disk WAL compatibility and will result in possibly
unrecoverable databases as soon as someone applies it; not to mention
what will happen if an HS slave is not running the same code as its
master. This must be treated as an initdb-forcing, or at least
pg_resetxlog-forcing, change.
The correct thing to do when committing such a change is to change the
WAL-file magic number XLOG_PAGE_MAGIC.
regards, tom lane
On Fri, 2010-03-19 at 08:41 -0400, Tom Lane wrote:
sriggs@postgresql.org (Simon Riggs) writes:
Log Message:
-----------
Reset btpo.xact following recovery of btree delete page. Add btpo_xact
field into WAL record and reset it from there, rather than using
FrozenTransactionId which can lead to some corner case bugs.Simon, you can't just whack WAL record contents around without a care.
This commit breaks on-disk WAL compatibility and will result in possibly
unrecoverable databases as soon as someone applies it; not to mention
what will happen if an HS slave is not running the same code as its
master. This must be treated as an initdb-forcing, or at least
pg_resetxlog-forcing, change.
OK, understood.
The correct thing to do when committing such a change is to change the
WAL-file magic number XLOG_PAGE_MAGIC.
Will do
--
Simon Riggs www.2ndQuadrant.com