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