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
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? |