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: | CAHGQGwGhawiSbuQaCVNS1QtmaJTHh3nw6kHoNrkOJ6TWxoFJ+A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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:
http://www.postgresql.org/docs/devel/static/runtime-config-replication.html#GUC-MAX-STANDBY-STREAMING-DELAY
---------------
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.
---------------
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Jon Nelson | 2012-01-31 15:38:07 | inet subtraction fails with IPv6? |
Previous Message | Alvaro Herrera | 2012-01-31 15:03:07 | Re: BUG #6200: standby bad memory allocations on SELECT |