On Tue, Feb 3, 2009 at 9:40 AM, Simon Riggs <si...@2ndquadrant.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. > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
