On Sat, 2010-05-15 at 11:45 -0400, Tom Lane wrote: > Simon Riggs <si...@2ndquadrant.com> writes: > > Patch adds a keepalive message to ensure max_standby_delay is useful. > > The proposed placement of the keepalive-send is about the worst it could > possibly be. It needs to be done right before pq_flush to ensure > minimum transfer delay. Otherwise any attempt to measure clock skew > using the timestamp will be seriously off. Where you've placed it > guarantees maximum delay not minimum.
I don't understand. WalSndKeepAlive() contains a pq_flush() immediately after the timestamp is set. I did that way for exactly the same reasons you've said. Do you mean you only want to see one pq_flush()? I used two so that the actual data is never delayed by a keepalive. WAL Sender was going to sleep anyway, so shouldn't be a problem. > I'm also extremely dubious that it's a good idea to set > recoveryLastXTime from this. Using both that and the timestamps from > the wal log flies in the face of everything I remember about control > theory. We should be doing only one or only the other, I think. I can change it so that the recoveryLastXTime will not be updated if we are using the value from the keepalives. So we have one, or the other. Remember that replication can switch backwards and forwards between modes, so it seems sensible to have a common timing value whichever mode we're in. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers