Re: Summary and Plan for Hot Standby - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Summary and Plan for Hot Standby
Date
Msg-id 1258305569.14054.2089.camel@ebony
Whole thread Raw
In response to Re: Summary and Plan for Hot Standby  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Summary and Plan for Hot Standby
List pgsql-hackers
On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:

> The assumption that b-tree vacuum records don't need conflict
> resolution because we did that with the additional cleanup-info record
> works ATM, but it hinges on the fact that we don't delete any tuples
> marked as killed while we do the vacuum. 

> That seems like a low-hanging
> fruit that I'd actually like to do now that I spotted it, but will
> then need to fix b-tree vacuum records accordingly. We'd probably need
> to do something about the previous item first to keep performance
> acceptable.

We can optimise that by using the xlog pointer of the HeapInfo record.
Any blocks cleaned that haven't been further updated can avoid
generating further btree deletion records. If you do this the
straightforward way then it will just generate a stream of btree
deletion records that will ruin usability.

You spotted this issue only this morning??

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Summary and Plan for Hot Standby
Next
From: Heikki Linnakangas
Date:
Subject: Re: Summary and Plan for Hot Standby