Thread: Re: [COMMITTERS] pgsql: Reset btpo.xact following recovery of btree delete page.
Re: [COMMITTERS] pgsql: Reset btpo.xact following recovery of btree delete page.
From
Tom Lane
Date:
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
Re: [COMMITTERS] pgsql: Reset btpo.xact following recovery of btree delete page.
From
Simon Riggs
Date:
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