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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
