public inbox for [email protected]
help / color / mirror / Atom feedhot_standby_feedback and max_standby_archive_delay
5+ messages / 3 participants
[nested] [flat]
* hot_standby_feedback and max_standby_archive_delay
@ 2014-01-16 23:38 Marko Tiikkaja <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Marko Tiikkaja @ 2014-01-16 23:38 UTC (permalink / raw)
To: pgsql-docs
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
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
***************
*** 1810,1818 **** if (!triggered)
situation will be no worse than if the standby queries were running
directly on the primary server, and you are still getting the benefit of
off-loading execution onto the standby.
! <varname>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.
</para>
<para>
--- 1810,1820 ----
situation will be no worse than if the standby queries were running
directly on the primary server, and you are still getting the benefit of
off-loading execution onto the standby.
! If a standby loses connectivity to the master, its
! <varname>hot_standby_feedback</> value is not respected by the master until
! the connection has been restored. If the slave wishes to continue
! executing queries in that case, its <varname>max_standby_archive_delay</>
! should be kept large.
</para>
<para>
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Attachments:
[text/plain] hot_standby_feedback.patch (1.1K, 2-hot_standby_feedback.patch)
download | inline diff:
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
***************
*** 1810,1818 **** if (!triggered)
situation will be no worse than if the standby queries were running
directly on the primary server, and you are still getting the benefit of
off-loading execution onto the standby.
! <varname>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.
</para>
<para>
--- 1810,1820 ----
situation will be no worse than if the standby queries were running
directly on the primary server, and you are still getting the benefit of
off-loading execution onto the standby.
! If a standby loses connectivity to the master, its
! <varname>hot_standby_feedback</> value is not respected by the master until
! the connection has been restored. If the slave wishes to continue
! executing queries in that case, its <varname>max_standby_archive_delay</>
! should be kept large.
</para>
<para>
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: hot_standby_feedback and max_standby_archive_delay
@ 2014-02-02 16:08 Fujii Masao <[email protected]>
parent: Marko Tiikkaja <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Fujii Masao @ 2014-02-02 16:08 UTC (permalink / raw)
To: Marko Tiikkaja <[email protected]>; +Cc: pgsql-docs
On Fri, Jan 17, 2014 at 8:38 AM, Marko Tiikkaja <[email protected]> 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
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: hot_standby_feedback and max_standby_archive_delay
@ 2014-04-16 18:51 Bruce Momjian <[email protected]>
parent: Fujii Masao <[email protected]>
0 siblings, 2 replies; 5+ messages in thread
From: Bruce Momjian @ 2014-04-16 18:51 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: Marko Tiikkaja <[email protected]>; pgsql-docs
On Mon, Feb 3, 2014 at 01:08:44AM +0900, Fujii Masao wrote:
> On Fri, Jan 17, 2014 at 8:38 AM, Marko Tiikkaja <[email protected]> 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 <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Attachments:
[text/x-diff] streaming.diff (1.5K, 2-streaming.diff)
download | inline diff:
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
new file mode 100644
index ecb51c4..39d7467
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
*************** if (!triggered)
*** 1889,1897 ****
situation will be no worse than if the standby queries were running
directly on the primary server, and you are still getting the benefit of
off-loading execution onto the standby.
! <varname>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.
</para>
<para>
--- 1889,1902 ----
situation will be no worse than if the standby queries were running
directly on the primary server, and you are still getting the benefit of
off-loading execution onto the standby.
! If standby servers connect and disconnect frequently, you
! might want to make adjustments to handle the period when
! <varname>hot_standby_feedback</> feedback is not being provided.
! For example, consider increasing <varname>max_standby_archive_delay</>
! so that queries are not rapidly cancelled by conflicts in WAL archive
! files during disconnected periods. You should also consider increasing
! <varname>max_standby_streaming_delay</> to avoid rapid cancellations
! by newly-arrived streaming WAL entries after reconnection.
</para>
<para>
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: hot_standby_feedback and max_standby_archive_delay
@ 2014-04-17 14:53 Bruce Momjian <[email protected]>
parent: Bruce Momjian <[email protected]>
1 sibling, 0 replies; 5+ messages in thread
From: Bruce Momjian @ 2014-04-17 14:53 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: Marko Tiikkaja <[email protected]>; pgsql-docs
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 <[email protected]> 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 <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: hot_standby_feedback and max_standby_archive_delay
@ 2014-04-18 12:12 Marko Tiikkaja <[email protected]>
parent: Bruce Momjian <[email protected]>
1 sibling, 0 replies; 5+ messages in thread
From: Marko Tiikkaja @ 2014-04-18 12:12 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; Fujii Masao <[email protected]>; +Cc: pgsql-docs
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
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2014-04-18 12:12 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2014-01-16 23:38 hot_standby_feedback and max_standby_archive_delay Marko Tiikkaja <[email protected]>
2014-02-02 16:08 ` Fujii Masao <[email protected]>
2014-04-16 18:51 ` Bruce Momjian <[email protected]>
2014-04-17 14:53 ` Bruce Momjian <[email protected]>
2014-04-18 12:12 ` Marko Tiikkaja <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox