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