Re: BUG #6423: max_standby_streaming_delay does not work
От | Fujii Masao |
---|---|
Тема | Re: BUG #6423: max_standby_streaming_delay does not work |
Дата | |
Msg-id | CAHGQGwGhawiSbuQaCVNS1QtmaJTHh3nw6kHoNrkOJ6TWxoFJ+A@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #6423: max_standby_streaming_delay does not work (139669962@qq.com) |
Список | pgsql-bugs |
On Tue, Jan 31, 2012 at 6:35 PM, <139669962@qq.com> wrote: > The following bug has been logged on the website: > > Bug reference: =A0 =A0 =A06423 > Logged by: =A0 =A0 =A0 =A0 =A0Weiyu Zhao > Email address: =A0 =A0 =A0139669962@qq.com > PostgreSQL version: 9.0.6 > Operating system: =A0 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: =A0terminating connection due to conflict with recovery > CSTDETAIL: =A0User query might have needed to see row versions that must = be > removed. > CSTHINT: =A0In a moment you should be able to reconnect to the database a= nd > 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, --=20 Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-bugs по дате отправления: