Re: Sync Rep for 2011CF1

On 08.02.2011 20:53, Robert Haas wrote:
> That having been said, there is at least one part of this patch which
> looks to be in pretty good shape and seems independently useful
> regardless of what happens to the rest of it, and that is the code
> that sends replies from the standby back to the primary. This allows
> pg_stat_replication to display the write/flush/apply log positions on
> the standby next to the sent position on the primary, which as far as
> I am concerned is pure gold. Simon had this set up to happen only
> when synchronous replication or XID feedback in use, but I think
> people are going to want it even with plain old asynchronous
> replication, because it provides a FAR easier way to monitor standby
> lag than anything we have today. I've extracted this portion of the
> patch, cleaned it up a bit, written docs, and attached it here.

Thanks!

> I wasn't too sure how to control the timing of the replies. It's
> worth noting that you have to send them pretty frequently for the
> distinction between xlog written and xlog flushed to have any value.
> What I've done here is made it so that every time we read all
> available data on the socket, we send a reply. After flushing, we
> send another reply. And then just for the heck of it we send a reply
> at least every 10 seconds (configurable), which causes the
> last-known-apply position to eventually get updated on the master.
> This means the apply position can lag reality by a bit.

Seems reasonable. As the patch stands, however, the standby doesn't send
any status updates if its busy receiving, writing, and flushing the
incoming WAL. That would happen if you have a fast network, and slow
disk, and the standby is catching up, e.g after restoring a base backup.

I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it
also sends a status update every time the WAL is flushed. If the
walreceiver is busy receiving and flushing, that would happen once per
WAL segment, which seems sensible.

The comment above StandbyReplyMessage said that its message type is 'r'.
However, no message type was actually sent for the replies. A message
type byte seems like a good idea, for the sake of extensibility, so I
made the code match that comment. I also added documentation of this new
message type in the manual section about the streaming replication protocol.

I committed the patch with those changes, and some minor comment tweaks
and other kibitzing.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com