From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: max_standby_delay considered harmful |
Date: | 2010-05-05 13:46:15 |
Message-ID: | 4BE176A7.20902@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Nikhil Sontakke | 2010-05-05 13:53:13 | possible memory leak with SRFs |
Previous Message | Andrew Dunstan | 2010-05-05 12:29:01 | Re: buildfarm building all live branches from git |