Re: Hot Standby (v9d)

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Hannu Krosing <hannu(at)krosing(dot)net>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, jd(at)commandprompt(dot)com, Gregory Stark <stark(at)enterprisedb(dot)com>, Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot Standby (v9d)
Date: 2009-02-03 14:40:26
Message-ID: 1233672026.4500.160.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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...

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)

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.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2009-02-03 14:42:42 Re: Hot Standby (v9d)
Previous Message Hannu Krosing 2009-02-03 14:35:35 Re: Hot Standby (v9d)