On Thu, May 27, 2010 at 9:08 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> * New process: WALAck (on standby)
> Reads shared memory to get last received and last applied xlog location
> and sends message to WALSync on primary. Loop/Sleep forever.
So would WALAck be polling shared memory? That would increase latency
significantly, I think, though perhaps you have a plan for avoiding
that?
> The above needs just two parameters at user level
> synch_rep = none | recv | apply
> synch_rep_timeout = Ns
> and an additional parameter in recovery.conf to say whether a standby is
> providing the facility for sync replication (as requested by Yeb etc)
> (default = yes).
>
> So this is the same as having quorum = 0 or 1 (boring but simple) and
> having sync_rep_timeout_action = commit in all cases (clear behaviour in
> failure modes, without need for per-standby parameters).
This seems good, but I think we need a little more definition about
what happens with sync_rep_timeout expires.
> Yes, this is a 3rd design for sync rep, though I think it improves upon
> the things I've heard so far from other authors and also includes
> feedback from Dimitri, Heikki, Yeb, Alastair. I'm happy to code this as
> well, when 9.1 dev starts and a benchmark should be interesting also.
It's great that we have so many people who want to implement this
feature, or in one case already have. I'm not sure whose design is
best, but I do hope that we can avoid dueling patches. There are
plenty of other good features to work on also.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
