From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
---|---|
To: | Kaijiang Chen <chenkaijiang(at)gmail(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: pg_dump's results have quite different size |
Date: | 2016-12-20 22:31:16 |
Message-ID: | 64ff0564-b55e-fc83-4154-d98a3ce958d5@catalyst.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 20/12/16 23:38, Kaijiang Chen wrote:
> After I enlarged the max_standby_streaming_delay, it works well for some
> days (I have to increase the max_standby_streaming_delay when data is
> bigger).
>
> Thank you all!
>
> A suggestion might be: pg_dump from the standby is frequently used in
> backup tasks; it'll be much better if we have some options to ensure the
> pg_dump to finish; for example, an option to temporary stop the
> replication? Or do we already have some approach?
>
You could perhaps pause replay on the standby before the dump [1], and
resume it afterwards. This is a bit clumsy, but is easy to implement as
part of the dump process.
regards
Mark
[1] functions pg_xlog_replay_pause() and pg_xlog_replay_resume()
From | Date | Subject | |
---|---|---|---|
Next Message | joan | 2016-12-20 23:33:52 | BUG #14470: Dropping a column produces "table row type and query-specified row type do not match" error |
Previous Message | Keith Fiske | 2016-12-20 17:04:32 | Re: 9.6rc1 Background worker starting multiple times |