Simon Riggs wrote:
> Introduce WAL records to log reuse of btree pages, allowing conflict
> resolution during Hot Standby. Page reuse interlock requested by Tom.
> Analysis and patch by me.

There's still a theoretical possibility for this to happen:

1. A page is marked as deleted by VACUUM, setting xact field in the opaque
2. Master crashes. WAL replay replays the XLOG_BTREE_DELETE_PAGE record.
It resets the xact field to FrozenTransactionId
3. The page is recycled. This writes a XLOG_BTREE_REUSE_PAGE record with
FrozenTransactionId as latestRemovedXid

When the standby replays that, it will call
ResolveRecoveryConflictWithSnapshot with FrozenTransactionid, not the
original xid that was used in the master when the page was deleted.

A straightforward way to fix that is to WAL-log the real xid in the
XLOG_BTREE_DELETE_PAGE records, instead of resetting it to
FrozenTransactionId.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

In response to

• pgsql: Introduce WAL records to log reuse of btree pages, allowing at 2010-02-13 00:59:58 from Simon Riggs

Responses

• Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing at 2010-02-18 17:16:57 from Simon Riggs
• Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing at 2010-03-19 11:07:07 from Simon Riggs

pgsql-hackers by date

Next:	From: Heikki Linnakangas	Date: 2010-02-18 12:46:46
	Subject: Re: Streaming replication on win32, still broken
Previous:	From: Robert Haas	Date: 2010-02-18 12:17:40
	Subject: Re: A thought: should we run pgindent now?

pgsql-committers by date

Next:	From: Simon Riggs	Date: 2010-02-18 17:16:57
	Subject: Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing
Previous:	From: Fujii Masao	Date: 2010-02-18 11:37:18
	Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL