Re: [COMMITTERS] pgsql: Reset btpo.xact following recovery of btree delete page.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Reset btpo.xact following recovery of btree delete page.
Date: 2010-03-19 12:41:23
Message-ID: 29112.1269002483@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

sriggs(at)postgresql(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2010-03-19 12:43:34 Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous Message Heikki Linnakangas 2010-03-19 11:37:08 Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-03-19 12:43:34 Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous Message Tom Lane 2010-03-19 12:18:27 Re: [BUG] SECURITY DEFINER on call handler makes daemon crash