Re: Sync Replication with transaction-controlled durability

On Fri, Oct 8, 2010 at 11:10 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Tue, 2010-09-14 at 18:48 +0100, Simon Riggs wrote:
>
>> I'm working on a patch to implement synchronous replication for
>> PostgreSQL, with user-controlled durability specified on the master. The
>> design also provides high throughput by allowing concurrent processes to
>> handle the WAL stream. The proposal requires only 3 new parameters and
>> takes into account much community feedback on earlier ideas.
>
> I'm now implementing v5, which simplifies the parameters still further
>
> USERSET on master
> * synchronous_replication = off (default) | on
> * synchronous_replication_timeout >=0 default=0 means wait forever
>
> set in postgresql.conf on standby
> * synchronous_replication_service = on (default) | off
>
> WALwriter is not active, nor are multiple sync rep modes available.
> Coding allows us to extend number of modes in future.
>
> Coding also solves problem raised by Dimitri: we don't advertise the
> sync rep service until the standby has caught up.
>
> This patch is a rough WIP, mostly stripping out and streamlining. It
> doesn't work yet, but people say they like to see me working, so here
> 'tis.

It seems like it would be more helpful if you were working on
implementing a design that had more than one vote.  As far as I can
tell, we have rough consensus that for the first commit we should only
worry about the case where k = 1; that is, only one ACK is ever
required for commit; and Greg Smith spelled out some more particulars
for a minimum acceptable implementation in the second part of the
email found here:

http://archives.postgresql.org/pgsql-hackers/2010-10/msg00384.php

That proposal is, AFAICT, the ONLY one that has got more than one
vote, and certainly the only one that has got as many votes as that
one does.  If you want to implement that, then I think we could reach
critical consensus on committing it very quickly.  If you DON'T want
to implement that proposal, then I suggest that we let Fujii Masao or
Heikki implement and commit it.  I realize, as you've pointed out
before, that there is no danger of missing 9.1 at this point, but on
the flip side I don't see that there's anything to be gained by
spending another month rehashing the topic when there's a good
proposal on the table that's got some momentum behind it.  Let's not
make this more complicated than it needs to be.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company