Re: Non-pausing table scan on 9.6 replica?
| От | Andreas Kretschmer |
|---|---|
| Тема | Re: Non-pausing table scan on 9.6 replica? |
| Дата | |
| Msg-id | 1030367a-f503-3755-0edf-c2c12c498585@a-kretschmer.de обсуждение исходный текст |
| Ответ на | Re: Non-pausing table scan on 9.6 replica? (Mark Fletcher <markf@corp.groups.io>) |
| Список | 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@a-kretschmer.de <mailto:andreas@a-kretschmer.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
В списке pgsql-general по дате отправления: