From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Summary and Plan for Hot Standby |
Date: | 2009-11-15 14:47:41 |
Message-ID: | 407d949e0911150647i48e82931va48a997a366c6b09@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Nov 15, 2009 at 2:32 PM, Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2009-11-15 14:50:03 | Re: Summary and Plan for Hot Standby |
Previous Message | Simon Riggs | 2009-11-15 14:32:58 | Re: Summary and Plan for Hot Standby |