On Wed, 2010-09-15 at 11:54 +0300, Heikki Linnakangas wrote:
> On 14/09/10 20:48, Simon Riggs wrote:
> > When each new messages arrives from master the WALreceiver will write
> > the new data to the WAL file, wake the WALwriter and then reply. Each
> > new message from master receives a reply. If no further WAL data has
> > been received the WALreceiver waits on the latch. If the WALReceiver is
> > woken by WALWriter or Startup then it will reply to master with a
> > message, even if no new WAL has been received.
>
> Wrt. the earlier discussion about when the standby sends the
> acknowledgment, this is the key paragraph. So you *are* sending multiple
> acknowledgments per transaction, but there is some smarts to combine
> them when there's a lot of traffic. Fair enough.
Not really. It's a simple design that works on chunks of WAL data, not
individual transactions. There is literally zero code executed to
achieve that, nor is bandwidth expended passing additional information.
"Smarts" tends to imply some complex optimization, whereas this is the
best optimization of all: no code whatsoever "per transaction".
If no new WAL is received then we do two extra messages, that's all, but
those replies only occur when the inbound path is otherwise quiet.
In typical case of a busy system there is one reply per chunk of WAL.
Since we already piggyback WAL writes into chunks in XLogWrite() that
means each reply acknowledges many transactions and there are zero
additional messages. Fast, efficient, no extra code.
When there is only one commit in a chunk of WAL data *and* the standby
is configured for 'apply' *and* nothing else occurs afterwards for some
time (long enough for an fsync and an apply, so at least 10ms), there
will be 3 replies for one transaction. That won't be the typical case
and even when it does happen its not a problem because the server is
otherwise quiet (by definition).
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services
