Thread: hot_standby_feedback and max_standby_archive_delay
Hi, Myself and others found this statement in the documentation about $SUBJECT very confusing: "max_standby_archive_delay must be kept large in this case, because delayed WAL files might already contain entries that conflict with the desired standby queries.". After a chat with Andres I've tried to make it clearer what said statement tries to convey. Did I succeed? Regards, Marko Tiikkaja
Attachment
On Fri, Jan 17, 2014 at 8:38 AM, Marko Tiikkaja <marko@joh.to> wrote: > Hi, > > Myself and others found this statement in the documentation about $SUBJECT > very confusing: "max_standby_archive_delay must be kept large in this case, > because delayed WAL files might already contain entries that conflict with > the desired standby queries.". After a chat with Andres I've tried to make > it clearer what said statement tries to convey. > > Did I succeed? Don't we need to increase also max_standby_streaming_delay in the case that you mentioned in the patch? When the standby successfully reconnects to the master, lots of WAL files would be streamed and they might already have WAL entries that conflict with standby queries. No? Regards, -- Fujii Masao
On Mon, Feb 3, 2014 at 01:08:44AM +0900, Fujii Masao wrote: > On Fri, Jan 17, 2014 at 8:38 AM, Marko Tiikkaja <marko@joh.to> wrote: > > Hi, > > > > Myself and others found this statement in the documentation about $SUBJECT > > very confusing: "max_standby_archive_delay must be kept large in this case, > > because delayed WAL files might already contain entries that conflict with > > the desired standby queries.". After a chat with Andres I've tried to make > > it clearer what said statement tries to convey. > > > > Did I succeed? > > Don't we need to increase also max_standby_streaming_delay > in the case that you mentioned in the patch? When the standby > successfully reconnects to the master, lots of WAL files would > be streamed and they might already have WAL entries that > conflict with standby queries. No? I have developed the attached doc patch to improve the wording on this topic. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Attachment
On Wed, Apr 16, 2014 at 02:51:15PM -0400, Bruce Momjian wrote: > On Mon, Feb 3, 2014 at 01:08:44AM +0900, Fujii Masao wrote: > > On Fri, Jan 17, 2014 at 8:38 AM, Marko Tiikkaja <marko@joh.to> wrote: > > > Hi, > > > > > > Myself and others found this statement in the documentation about $SUBJECT > > > very confusing: "max_standby_archive_delay must be kept large in this case, > > > because delayed WAL files might already contain entries that conflict with > > > the desired standby queries.". After a chat with Andres I've tried to make > > > it clearer what said statement tries to convey. > > > > > > Did I succeed? > > > > Don't we need to increase also max_standby_streaming_delay > > in the case that you mentioned in the patch? When the standby > > successfully reconnects to the master, lots of WAL files would > > be streamed and they might already have WAL entries that > > conflict with standby queries. No? > > I have developed the attached doc patch to improve the wording on this > topic. Patch applied. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
On 4/16/14, 9:51 PM, Bruce Momjian wrote: > I have developed the attached doc patch to improve the wording on this > topic. I think this is an eloquent phrasing of my understanding of what the original text tried to convey. Regards, Marko Tiikkaja