On Tue, 2010-10-19 at 09:36 -0700, Josh Berkus wrote:
> >> 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?
Sure. It's a documented workaround.
> > 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.
Yes, I thought to extend hot_standby parameter to have 3 modes:
off (default) | on | feedback
> > 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.
I agree many people won't use the standby for reads.
Why then would they care about the difference between fsync and apply?
Anyway, that suggestion is mainly so we can reach agreement on a minimal
patch, not suggesting it as a limit on released functionality.
-- Simon Riggs http://www.2ndquadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services