Re: Sync Rep Design - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Sync Rep Design
Date
Msg-id 4D1E7366.1020607@postgresql.org
Whole thread Raw
In response to Re: Sync Rep Design  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pl/python refactoring
Next
From: Jim Nasby
Date:
Subject: Re: estimating # of distinct values