From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: max_standby_delay considered harmful |
Date: | 2010-05-06 15:38:18 |
Message-ID: | AANLkTiljAwtVO2Q0WBWyyWORq3Y0GJedKYUb3LmjXMuk@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 3, 2010 at 11:37 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm inclined to think that we should throw away all this logic and just
> have the slave cancel competing queries if the replay process waits
> more than max_standby_delay seconds to acquire a lock. This is simple,
> understandable, and behaves the same whether we're reading live data or
> not.
Now that I've realized what the real problem is with max_standby_delay
(namely, that inactivity on the master can use up the delay), I think
we should do what Tom originally suggested here. It's not as good as
a really working max_standby_delay, but we're not going to have that
for 9.0, and it's clearly better than a boolean.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-05-06 15:43:09 | Re: Adding xpath_exists function |
Previous Message | Alvaro Herrera | 2010-05-06 15:32:39 | Re: pg_migrator to /contrib in a later 9.0 beta |