Simon Riggs wrote:
> On Fri, 2010-01-15 at 20:50 +0200, Heikki Linnakangas wrote:
>
>>> So in either case, when we are waiting for new input we reset the timer
>>> as soon as new WAL is received. The resolution/accuracy of standby_delay
>>> will be no more than the time taken to replay a single file. This
>>> shouldn't matter, since sane settings of max_standby_delay are either 0
>>> or a number like 5-20 (seconds).
>> That would change the meaning of max_standby_delay. Currently, it's the
>> delay between *generating* and applying a WAL record, your proposal
>> would change it to mean delay between receiving and applying it. That
>> seems a lot less useful to me.
>
> Remember that this proposal is about responding to your comments. You
> showed that the time difference between generating and applying a WAL
> record lacked useful meaning in cases where the generation was not
> smooth and continuous.
Yeah, I remember that. What the DBA cares about is the time between a
commit record being generated in the master, and the same record being
applied in the standby. That's easy to explain and tune for, and that's
what max_standby_delay should be. Let's not redefine it into something
less useful just because there's corner cases where we can't calculate
it easily.
The standby would really need to know the timestamp of the *next* commit
record in the WAL. Next from the record that's being applied. We don't
want to peek ahead, and we might not even have received the next commit
record yet even if it's already been generated in master, so we
approximate the timestamp of next commit record with timetamp of
previous commit record.
> It would be good if there was a keepalive WAL record with a timestamp on
> it generated every N seconds while in streaming mode.
Yeah, that would help. In streaming replication we could also send such
timestamp as a separate message, not within WAL.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com