Fujii Masao wrote:
On Thu, Jun 10, 2010 at 5:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com 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
Bruce Momjian br...@momjian.us writes:
Fujii Masao wrote:
On Thu, Jun 10, 2010 at 5:06 AM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Jun 10, 2010 at 5:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com 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,
On Thu, Jun 10, 2010 at 9:58 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Fujii Masao masao.fu...@gmail.com 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
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 Fri, Jun 11, 2010 at 1:48 AM, Josh Berkus j...@agliodbs.com 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
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
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
Fujii Masao masao.fu...@gmail.com 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
On Wed, Jun 9, 2010 at 5:47 PM, Fujii Masao masao.fu...@gmail.com 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
On Wed, Jun 9, 2010 at 6:13 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp 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
Fujii Masao masao.fu...@gmail.com 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
Josh Berkus j...@agliodbs.com 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
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 the
On Wed, Jun 9, 2010 at 3:22 PM, Josh Berkus j...@agliodbs.com 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.
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 some
Fujii Masao masao.fu...@gmail.com 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
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 from
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
19 matches
Mail list logo
