Re: pg_dump's results have quite different size

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()

In response to

Browse pgsql-bugs by date

  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