Skip site navigation (1) Skip section navigation (2)

Re: BUG #6423: max_standby_streaming_delay does not work

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: 139669962(at)qq(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6423: max_standby_streaming_delay does not work
Date: 2012-01-31 15:19:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Tue, Jan 31, 2012 at 6:35 PM,  <139669962(at)qq(dot)com> wrote:
> The following bug has been logged on the website:
> Bug reference:      6423
> Logged by:          Weiyu Zhao
> Email address:      139669962(at)qq(dot)com
> PostgreSQL version: 9.0.6
> Operating system:   Redhat 5.5 x86_64
> Description:
> The parameter max_standby_streaming_delay does not work. The parameter is
> set 30s. My queries' duration is about 7 or 8 seconds. I still encounter
> errors:
> CSTFATAL:  terminating connection due to conflict with recovery
> CSTDETAIL:  User query might have needed to see row versions that must be
> removed.
> CSTHINT:  In a moment you should be able to reconnect to the database and
> repeat your command.
> I have a test case, but I don't know how to upload it.

The following note in the document would help:
Note that max_standby_streaming_delay is not the same as the maximum
length of time a query can run before cancellation; rather it is the
maximum total time allowed to apply WAL data once it has been received
from the primary server. Thus, if one query has resulted in
significant delay, subsequent conflicting queries will have much less
grace time until the standby server has caught up again.


Fujii Masao
NTT Open Source Software Center

In response to

pgsql-bugs by date

Next:From: Jon NelsonDate: 2012-01-31 15:38:07
Subject: inet subtraction fails with IPv6?
Previous:From: Alvaro HerreraDate: 2012-01-31 15:03:07
Subject: Re: BUG #6200: standby bad memory allocations on SELECT

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group