Re: Synchronous replication - patch status inquiry

On Tue, 2010-09-07 at 09:27 +0300, Heikki Linnakangas wrote:
> On 06/09/10 17:14, Simon Riggs wrote:
> > On Mon, 2010-09-06 at 16:14 +0300, Heikki Linnakangas wrote:
> >>>
> >>> The standby is sending a stream of messages to the master with current
> >>> LSN positions at the time the message is sent. Given a synchronous
> >>> transaction, the master would wait until the feedback stream reports
> >>> that the current transaction is in the past compared to the streamed
> >>> last known synced one (or the same).
> >>
> >> That doesn't really answer the question: *when* does standby send back
> >> the acknowledgment?
> >
> > I think you should explain when you think this happens in your proposal.
> >
> > Are you saying that you think the standby should send back one message
> > for every transaction? That you do not think we should buffer the return
> > messages?
>
> For the sake of argument, yes that's what I was thinking. Now please
> explain how *you're* thinking it should work.

The WAL is sent from master to standby in 8192 byte chunks, frequently
including multiple commits. From standby, one reply per chunk. If we
need to wait for apply while nothing else is received, we do.

> > You seem to be proposing a design for responsiveness to a single
> > transaction, not for overall throughput. That's certainly a design
> > choice, but it wouldn't be my recommendation that we did that.
>
> Sure, if there's more traffic, you can combine things. For example, if
> one fsync in the standby flushes more than one commit record, you only
> need one acknowledgment for all of them.

> But don't dodge the question!

Given that I've previously outlined the size and contents of request
packets, their role and frequency I don't think I've dodged anything; in
fact, I've almost outlined the whole design for you.

I am coding something to demonstrate the important aspects I've
espoused, just as you have done in the past when I didn't appreciate
and/or understand your ideas. That seems like the best way forwards
rather than wrangle through all the "that can't work" responses, which
actually takes longer.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services