On 12/31/10 4:40 AM, Robert Haas wrote:
> Someone may have proposed this before, but one way of getting standby
> naming "for free" would be to make the standby names the same as the
> roles used to log in, rather than adding a separate parameter.  We
> could just recommend to people that they use a separate, descriptive
> role name for each standby.  Then the synchronous_standbys parameter -
> when added - would mean "a standby from one of these roles".

I like this idea; it has an elegant simplicity about it and right now I
can't think of any real faults.  It would have the added benefit that
each standby "group" would show up by the group name in ps and on
pg_stat_activity.

However, I agree strongly with Simon that we really want the simplest
possible synch rep implementation for 9.1, given that we're currently 15
days away from the *last* commitfest.  Nobody, at this point, has really
even test any of the sync rep patches for reliability or performance.

Here's how I could see us developing:

Simplest (9.1):
-- synch/async capability set on the standby in recovery.conf
-- synch/async transaction status (async, recv, fsync, apply) declared
as a userset by the executing session (from Simon's patch)
-- only one ack for sync, regardless of the number of standbys

This would allow users to have a single sync standby plus a pool of
async standbys, which is what I think 90% of users who care about sync
standby want.

More Complex (9.2):
-- all of the above, *plus* the ability to have standbys with ROLEs and
require acks from one server in each ROLE.

"Web-Scale" (9.3):
-- all of the above, plus "group commit", the ability to specific a
number of servers in each ROLE who must ack.

... but the most important thing is to make the feature for 9.1 simple,
simple, simple.  We know we won't get it right on the first try.

--Josh Berkus

In response to

• Re: Sync Rep Design at 2010-12-31 12:40:15 from Robert Haas

pgsql-hackers by date

Next:	From: Jim Nasby	Date: 2011-01-01 03:24:26
	Subject: Re: estimating # of distinct values
Previous:	From: Peter Eisentraut	Date: 2011-01-01 00:00:03
	Subject: Re: pl/python refactoring