Re: Non-pausing table scan on 9.6 replica?

From: Andreas Kretschmer <andreas(at)a-kretschmer(dot)de>
To: Mark Fletcher <markf(at)corp(dot)groups(dot)io>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Non-pausing table scan on 9.6 replica?
Date: 2019-03-06 05:47:49
Message-ID: 1030367a-f503-3755-0edf-c2c12c498585@a-kretschmer.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Am 06.03.19 um 06:41 schrieb Mark Fletcher:
> Thank you for responding to my email.
>
> On Tue, Mar 5, 2019 at 9:20 PM Andreas Kretschmer
> <andreas(at)a-kretschmer(dot)de <mailto:andreas(at)a-kretschmer(dot)de>> wrote:
>
>
> have you set ```max_standby_streaming_delay``? The default is 30
> seconds, which means that this will be the maximum time allowed for a
> replication lag caused by a conflicting query.
>
>
> Yes, we've bumped that up a lot.

i tought so.

> You can use ``hot_standby_feedback = on``, but the downside will
> be more
> bloat on the tables.
>
> I'm not sure I understand. I'm not worried about the query being
> cancelled on the replica. max_standby_streaming_delay fixes that for
> us. I'm worried about the streaming replication being paused while
> this table scan is running. If the table scan takes several minutes,
> then the replica becomes several minutes out of sync with the master.
> I'd prefer that not to happen and I'm wondering if there's a way to do
> that.
>

You can choose. max_standby_streaming_delay with delay in the streaming
(hence the name) or hot_standby_feedback, with the downside of possible
more bloat.

Regards, Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sameer Kumar 2019-03-06 05:56:56 Re: Non-pausing table scan on 9.6 replica?
Previous Message Mark Fletcher 2019-03-06 05:41:06 Re: Non-pausing table scan on 9.6 replica?