Re: Hot Standby (v9d) - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Hot Standby (v9d)
Date
Msg-id 1233671735.7999.11.camel@huvostro
Whole thread Raw
In response to Re: Hot Standby (v9d)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, 2009-02-03 at 09:14 -0500, Robert Haas wrote:
> >> I don't see any way around the fact that when a tuple is removed, it's
> >> gone and can't be accessed by queries. Either you don't remove it, or
> >> you kill the query.
> >
> > Actually we came up with a solution to this - use filesystem level
> > snapshots (like LVM2+XFS or ZFS), and redirect backends with
> > long-running queries to use fs snapshot mounted to a different
> > mountpoint.
> >
> > I don't think Simon has yet put full support for it in code, but it is
> > clearly _the_ solution for those who want to eat the cake and have it
> > too.
> 
> I think _the_ solution is to notice when you're about to vacuum a page
> that is still visible to a running backend on the standby, and save
> that page off to a separate cache of old page versions (perhaps using
> the relation fork mechanism).  I suspect filesystem-level snapshots
> can be made to work, but it's never going to be a portable solution,
> and I suspect you're going to need a lot of the same bookkeeping
> anyway (like, when you have page X in shared buffers, which version of
> page X is it, anyway?).

The idea was to switch file pointers inside the backend needing old
versions, (and then flush cache if needed) so the only bookkeeping you
need is which fs snapshots you need to keep and which can be released.



-- 
------------------------------------------
Hannu Krosing   http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability   Services, Consulting and Training



pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Hot Standby (v9d)
Next
From: Simon Riggs
Date:
Subject: Re: Hot Standby (v9d)