From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: max_standby_delay considered harmful |
Date: | 2010-05-08 19:46:51 |
Message-ID: | AANLkTilE4_MV7SzP-s7DsR5iVU0nQj8gNgvi3A9yEMME@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, May 8, 2010 at 3:40 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> On Sat, May 8, 2010 at 2:48 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> > I think the concensus is to change this setting to a boolean. ?If you
>> > don't want to do it, I am sure we can find someone who will.
>>
>> I still think we should revert to Tom's original proposal.
>
> And Tom's proposal was to do it on WAL slave arrival time? If we could
> get agreement from everyone that that is the proper direction, fine, but
> I am hearing things like plugins, and other complexity that makes it
> seem we are not getting closer to an agreed solution, and without
> agreement, the simplest approach seems to be just to remove the part we
> can't agree upon.
>
> I think the big question is whether this issue is significant enough
> that we should ignore our policy of no feature design during beta.
Tom's proposal was basically to define recovery_process_lock_timeout.
The recovery process would wait X seconds for a lock, then kill
whoever held it. It's not the greatest knob in the world for the
reasons already pointed out, but I think it's still better than a
boolean and will be useful to some users. And it's pretty simple.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | James William Pye | 2010-05-08 20:00:46 | Re: plpython3 |
Previous Message | Bruce Momjian | 2010-05-08 19:40:09 | Re: max_standby_delay considered harmful |