Skip site navigation (1) Skip section navigation (2)

Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Simon Riggs <sriggs(at)postgresql(dot)org>, 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 17:16:57
Message-ID: 1266513417.7341.9863.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Thu, 2010-02-18 at 14:23 +0200, Heikki Linnakangas wrote:
> 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.

An even simpler way would be to reset the value to latestCompletedXid
during btree_xlog_delete_page(). That touches less code. I doubt it will
make much difference to conflict recovery, since if pages are being
deleted then btree delete records are likely to be frequent and will
have already killed long running queries.

-- 
 Simon Riggs           www.2ndQuadrant.com


In response to

Responses

pgsql-hackers by date

Next:From: David E. WheelerDate: 2010-02-18 17:50:27
Subject: Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl
Previous:From: Dimitri FontaineDate: 2010-02-18 16:54:31
Subject: Re: Avoiding bad prepared-statement plans.

pgsql-committers by date

Next:From: Tom LaneDate: 2010-02-18 18:41:47
Subject: pgsql: Fix ExecEvalArrayRef to pass down the old value of the array
Previous:From: Heikki LinnakangasDate: 2010-02-18 12:23:17
Subject: Re: [COMMITTERS] pgsql: Introduce WAL records to log reuse of btree pages, allowing

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group