Re: BUG #14321: pg_basebackup --xlog-method=stream fails

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: juergen+postgresql(at)strobel(dot)info
Cc: PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14321: pg_basebackup --xlog-method=stream fails
Date: 2016-09-09 22:09:02
Message-ID: CAB7nPqS3wouy++_zR_fCdRhK1YFLuUExUB1STzbcPRJjE-KC-Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, Sep 10, 2016 at 1:58 AM, <juergen+postgresql(at)strobel(dot)info> wrote:
> The filsystem backup continues successfully to its end, but it concludes
> without the necessary WAL files. I verified in pg_stat_replication that
> pg_basebackup is not trying to reconnect to the master.
>
> I understand how to repair this manually and it's not an end-of-the-world
> bug, but it would be nice if pg_basebackup would just reconnect the
> streaming WAL connection in the same way as pg_receivexlog does. Especially
> as that error happens in a long script run by cron and/or other people who
> do not have this insight.

Perhaps. The source server logs do prove the fact that pg_basebackup
is requesting for missing WAL segments, right?

> I haven't had time to try 9.6's --slot option yet, but I suspect this won't
> be a full cure either unless it also changes the re-connect behavior.

If what you are seeing missing are the first WAL segments that your
backup needs, first the backup you took will be useless if you don't
have a WAL archive from where recovery could fetch those missing
segments. And in this case --slot will definitely help, but just be
sure that this does not bloat your pg_xlog partition if disk space is
a concern there.
--
Michael

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message keith 2016-09-09 23:54:48 BUG #14322: Possible inconsistent behavior with timestamp_to_str()
Previous Message Xtra Coder 2016-09-09 19:11:54 Re: Performance issue: jsonb_object_agg() is twice slower than to_jsonb()