From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <sriggs(at)postgresql(dot)org> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing |
Date: | 2010-02-18 12:23:17 |
Message-ID: | 4B7D3135.3090204@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-02-18 17:16:57 | Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing |
Previous Message | Fujii Masao | 2010-02-18 11:37:18 | Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-02-18 12:46:46 | Re: Streaming replication on win32, still broken |
Previous Message | Robert Haas | 2010-02-18 12:17:40 | Re: A thought: should we run pgindent now? |