On Wed, 2010-05-05 at 16:46 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > The attached patch redefines "standby delay" to be the amount of time
> > elapsed from point of receipt to point of application. The "point of
> > receipt" is reset every chunk of data when streaming, or every file when
> > reading file by file. In all cases this new time is later than the
> > latest log time we would have used previously.
>
> This seems completely wrong to me. If the WAL receiver keeps receiving
> stuff, (last receive timestamp) - (current timestamp) would never be
> more than a few seconds. Regardless of how much applying the WAL has
> fallen behind.
I see your point.
> To accomplish what you're trying to accomplish, you would need to label
> each received WAL record with the timestamp when it was received, and
> compare the reception timestamp of the record you're applying against
> current timestamp.
Yes, OK. Obviously doing it for every record would be silly, so sampling
WAL records is the only way. If we save the timestamp every 16MB of WAL
that would work for both file and streaming.
Of course, if WAL was written regularly none of this would be a problem.
Why not have WALSender write a new WAL record with a timestamp every X
seconds?
-- Simon Riggs www.2ndQuadrant.com