Re: Hot Standby (v9d)

On Tue, 2009-02-03 at 10:19 -0500, Robert Haas wrote:
> On Tue, Feb 3, 2009 at 9:40 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > On Tue, 2009-02-03 at 09:14 -0500, Robert Haas wrote:
> >> 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'll let you write that, for the next release...
>
> LOL. How many sponsorship dollars are available for that project?
>
> > The problem with all of this is we've been talking about it for 8 months
> > now and various opinions are held by people. What is being presented is
> > a broad set of options (summarised from Wiki)
>
> I think everyone understands that these are things we might want to do
> down the line, not things we need to have now. For this release, I
> was under the impression that we'd pretty much settled on implementing
> (1) and maybe (3) but not (2) from the below list.

(2) is something that you can always do manually if you need it. So no
reason to support it in HS code explicitly.

Once you keep trx open on master, 1 and 3 should not happen anymore
until you close that trx.

> > 1. Wait then cancel
> > a) always for databases, tablespaces and locks
> > b) deferred cancelation for buffer changes
> >
> > 2. We connect to Primary server from Standby server and keep a
> > transaction open using contrib/dblink functions, then commit as soon as
> > we are done.
> >
> > 3. We pause recovery by issuing a pg_recovery_pause() function, or start
> > server in pause mode using recovery_started_paused = on.
> >
> > Yes, it's a critical area to the success of the feature. But this is
> > enough for first release and for us to get user feedback.
>
> I completely agree.
>
> ...Robert
>