Re: Issues with two-server Synch Rep

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

In response to

Responses

Browse pgsql-hackers by date

  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