From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Confusing error message with too-large file in pg_basebackup |
Date: | 2015-11-20 04:16:07 |
Message-ID: | CAB7nPqQjk-KYXfJWYKnySM_k14-5JsU0dEJt+q9ch+X0qbg1SA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Nov 20, 2015 at 9:37 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> pg_basebackup: could not get transaction log end position from server:
> ERROR: archive member "core" too large for tar format
That's a backend-side error.
> This was very confusing to the user, because they weren't requesting tar
> format, and even setting -Fp got the same error message. I can only
> hypothesize that tar is used somewhere under the hood.
Exactly, when a base backup is taken through the replication protocol,
backend always sends it in tar format for performance reasons. It is
then up to pg_basebackup to decide if the output should be untared or
not.
> pg_basebackup doesn't need to work under these circumstances, but maybe
> we could give a less baffling error message?
We would need to let the backend know about the output format expected
by the caller of BASE_BACKUP by extending the command in the
replication protocol. It does not sound like a good idea to me just to
make some potential error messages more verbose.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-11-20 04:41:34 | Re: Confusing error message with too-large file in pg_basebackup |
Previous Message | Josh Berkus | 2015-11-20 00:37:03 | Confusing error message with too-large file in pg_basebackup |