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

From Robert Haas
Subject Re: Hot Standby (v9d)
Date
Msg-id 603c8f070902030614s7ecdeb5eyf726c72fb858dc78@mail.gmail.com
Whole thread Raw
In response to Re: Hot Standby (v9d)  (Hannu Krosing <hannu@krosing.net>)
Responses Re: Hot Standby (v9d)  (Hannu Krosing <hannu@2ndQuadrant.com>)
Re: Hot Standby (v9d)  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
>> 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?).

...Robert


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Hot Standby (v9d)
Next
From: "Kevin Grittner"
Date:
Subject: Re: add_path optimization