On Sun, Nov 15, 2009 at 2:32 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> - The "standby delay" is measured as current timestamp - timestamp of >> last replayed commit record. If there's little activity in the master, >> that can lead to surprising results. For example, imagine that >> max_standby_delay is set to 8 hours. The standby is fully up-to-date >> with the master, and there's no write activity in master. After 10 >> hours, a long reporting query is started in the standby. Ten minutes >> later, a small transaction is executed in the master that conflicts with >> the reporting query. I would expect the reporting query to be canceled 8 >> hours after the conflicting transaction began, but it is in fact >> canceled immediately, because it's over 8 hours since the last commit >> record was replayed. > > An issue that will be easily fixable with streaming, since it > effectively needs a heartbeat to listen to. Adding a regular stream of > WAL records is also possible, but there is no need, unless streaming is > somehow in doubt. Again, there is work to do once both are in.
I don't think you need a heartbeat to solve this particular case. You just need to define the "standby delay" to be "current timestamp - timestamp of the conflicting candidate commit record". -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
