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
Hi,
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 downtime
a
19 matches
Mail list logo
