From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Issues with two-server Synch Rep |
Date: | 2010-10-19 16:36:42 |
Message-ID: | 4CBDC91A.3060707@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> Absolutely. For a synch standby, you can't tolerate any standby delay
>> at all. This means that anywhere from 1/4 to 3/4 of queries on the
>> standby would be cancelled on any high-traffic OLTP server. Hence,
>> "useless".
>
> Don't agree with your numbers there and you seem to be assuming no
> workarounds would be in use. A different discussion, I think.
The only viable workaround would be to delay vacuum on the master, no?
> Adding the feedback channel looks trivial to me, once we've got the main
> sync rep patch in. I'll handle that.
OK. I thought it would be a major challenge. Ideally, we'd have some
way to turn snapshot publication on or off; for a standby which was not
receiving reads, we wouldn't need it. Maybe make it contingent on the
status of hot_standby GUC? That would make sense.
> For this reason, I've removed the "apply" mode from my patch, for now. I
> want to get the simplest possible patch agreed and then add things
> later.
Um, ok. "apply" mode is still useful for users who are not running
queries against the standby. Which many won't.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-10-19 16:53:01 | Re: WIP: extensible enums |
Previous Message | Dimitri Fontaine | 2010-10-19 16:36:06 | Re: Extensions, this time with a patch |