Re: pg_dump's results have quite different size

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>, Kaijiang Chen <chenkaijiang(at)gmail(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: pg_dump's results have quite different size
Date: 2016-12-16 22:30:31
Message-ID: 543408b3-6724-3c13-16a2-4239aee99cd0@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 17/12/16 09:47, Jeff Janes wrote:

> On Thu, Dec 15, 2016 at 11:18 PM, Mark Kirkwood
> <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz <mailto:mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>>
> wrote:
>
> On 14/12/16 22:09, Oleksandr Shulgin wrote:
>
> On Wed, Dec 14, 2016 at 9:29 AM, Kaijiang Chen
> <chenkaijiang(at)gmail(dot)com <mailto:chenkaijiang(at)gmail(dot)com>
> <mailto:chenkaijiang(at)gmail(dot)com
> <mailto:chenkaijiang(at)gmail(dot)com>>> wrote:
>
> Yes. The pg_dump quits with the message:
>
> pg_dump: Dumping the contents of table "data_histories"
> failed:
> PQgetResult() failed.
> pg_dump: Error message from server: ERROR: canceling statement
> due to conflict with recovery
> DETAIL: User query might have needed to see row versions that
> must be removed.
> pg_dump: The command was: COPY public.data_histories (id,
> user_id,
> user_name, type, type_id, old_data, action, new_data,
> created_at,
> updated_at) TO stdout;
>
>
> Ah, then it's just that your backup script is broken: it
> should have reported the error.
>
> Please do not top-post.
>
>
> Oleksandr - how about a helpful response? E.g suggesting that
> maybe increasing max_standby_streaming_delay might help? Goddamn!
> folk asking for help deserve better than just being told 'it is
> broken dickhead'...
>
>
> The problem *is* that his backups are broken without him knowing it.
> Maybe increasing max_standby_streaming_delay is an answer, but maybe
> he would rather have occasional broken backups *which he knows about*
> then suffer the consequences of an increased
> max_standby_streaming_delay. Maybe hot_standby_feedback would be a
> better option, or maybe vacuum_defer_cleanup_age (but that is less
> likely).
>
> The only thing we actually know with reasonable certainty is that his
> backup script is broken, and that this is bad. Randomly changing
> settings so that the brokenness is still there but just less obvious
> is more dangerous than helpful.
>

It seems we know quite a lot more, evidenced by the error above. It also
seems clear that he wants his backups to work, not just report errors
surely? That the script should check return codes better (or at all)
sure, that seems to have been emphasized quite sufficiently.

regards

Mark

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message maxim.boguk 2016-12-17 10:53:46 BUG #14469: Wrong cost estimates for merge append plan with partitions.
Previous Message David G. Johnston 2016-12-16 21:32:29 Re: pg_dump's results have quite different size