Bruce Momjian writes:
> Fujii Masao wrote:
>> On Thu, Jun 10, 2010 at 5:06 AM, Tom Lane wrote:
>>> My feeling about it is that if you want fast failover you should not
>>> have your failover target server configured as hot standby at all, let
>>> alone hot standby with a long max_standby_delay.
Fujii Masao wrote:
> On Thu, Jun 10, 2010 at 5:06 AM, Tom Lane wrote:
> > Josh Berkus writes:
> >> The fact that failover current does *not* terminate existing queries and
> >> transactions was regarded as a feature by the audience, rather than a
> >> bug, when I did demos of HS/SR. ?Of course, t
On Fri, Jun 11, 2010 at 1:48 AM, Josh Berkus wrote:
> On 06/09/2010 07:36 PM, Mark Kirkwood wrote:
>>
>> On 10/06/10 14:07, Tatsuo Ishii wrote:
>>>
>>> The one of top 3 questions I got
>>> when we propose them our HA solution is, "how long will it take to
>>> do failover when the master DB crashes
On 06/09/2010 07:36 PM, Mark Kirkwood wrote:
On 10/06/10 14:07, Tatsuo Ishii wrote:
The one of top 3 questions I got
when we propose them our HA solution is, "how long will it take to
do failover when the master DB crashes?"
Same here +1
In that case, wouldn't they set max_standby_delay to
On Thu, Jun 10, 2010 at 9:58 AM, Takahiro Itagaki
wrote:
>
> Fujii Masao wrote:
>
>> > 1. Reset max_standby_delay = 0 in postgresql.conf
>> > 2. pg_ctl reload
>> > 3. Create a trigger file
>>
>> As far as I read the HS code, SIGHUP is not checked while a recovery
>> is waiting for queries :( So
On Thu, Jun 10, 2010 at 5:06 AM, Tom Lane wrote:
> Josh Berkus writes:
>> The fact that failover current does *not* terminate existing queries and
>> transactions was regarded as a feature by the audience, rather than a
>> bug, when I did demos of HS/SR. Of course, they might not have been
>> th
On 10/06/10 14:07, Tatsuo Ishii wrote:
The one of top 3 questions I got
when we propose them our HA solution is, "how long will it take to
do failover when the master DB crashes?"
Same here +1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
> The fact that failover current does *not* terminate existing queries and
> transactions was regarded as a feature by the audience, rather than a
> bug, when I did demos of HS/SR. Of course, they might not have been
> thinking of the delay for writes.
Probably you would hear different respose fr
Fujii Masao wrote:
> > 1. Reset max_standby_delay = 0 in postgresql.conf
> > 2. pg_ctl reload
> > 3. Create a trigger file
>
> As far as I read the HS code, SIGHUP is not checked while a recovery
> is waiting for queries :( So pg_ctl reload would have no effect on
> the conflicting queries.
>
On Wed, 2010-06-09 at 12:22 -0700, Josh Berkus wrote:
> > To fix the problem, when the trigger file is found, I think
> > that we should cancel all the running read only queries
> > immediately (or forcibly use -1 as the max_standby_delay
> > since that point) and make the recovery go ahead. If som
On Wed, Jun 9, 2010 at 3:22 PM, Josh Berkus wrote:
>
>> To fix the problem, when the trigger file is found, I think
>> that we should cancel all the running read only queries
>> immediately (or forcibly use -1 as the max_standby_delay
>> since that point) and make the recovery go ahead. If some
>>
> To fix the problem, when the trigger file is found, I think
> that we should cancel all the running read only queries
> immediately (or forcibly use -1 as the max_standby_delay
> since that point) and make the recovery go ahead. If some
> people prefer queries over failover even when they create
Josh Berkus writes:
> The fact that failover current does *not* terminate existing queries and
> transactions was regarded as a feature by the audience, rather than a
> bug, when I did demos of HS/SR. Of course, they might not have been
> thinking of the delay for writes.
> If there were an easy
Fujii Masao writes:
> When the trigger file is created while the recovery keeps
> waiting for the release of the lock by read only queries,
> it might take a very long time for the standby to become
> the master. The recovery cannot go ahead until those read
> only queries have gone away. This wou
On Wed, Jun 9, 2010 at 6:13 PM, Takahiro Itagaki
wrote:
>> To fix the problem, when the trigger file is found, I think
>> that we should cancel all the running read only queries
>> immediately (or forcibly use -1 as the max_standby_delay
>> since that point) and make the recovery go ahead.
>
> Hmm
On Wed, Jun 9, 2010 at 5:47 PM, Fujii Masao wrote:
> To fix the problem, when the trigger file is found, I think
> that we should cancel all the running read only queries
> immediately (or forcibly use -1 as the max_standby_delay
> since that point) and make the recovery go ahead.
Oops! I made an
Fujii Masao wrote:
> To fix the problem, when the trigger file is found, I think
> that we should cancel all the running read only queries
> immediately (or forcibly use -1 as the max_standby_delay
> since that point) and make the recovery go ahead.
Hmmm, does the following sequence work as you
> When the trigger file is created while the recovery keeps
> waiting for the release of the lock by read only queries,
> it might take a very long time for the standby to become
> the master. The recovery cannot go ahead until those read
> only queries have gone away. This would increase the downt
18 matches
Mail list logo
