From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, 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:41:34 |
Message-ID: | 11737.1447994494@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> 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.
It's not unreasonable for pg_basebackup to use tar format, because the
size limitation should not be an issue for files that are expected to
be in a data directory. Leftover core dump files are unexpected :-(.
I wonder if we could put some sort of filter into pg_basebackup so
it would skip this sort of thing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-11-20 05:25:24 | Re: Confusing error message with too-large file in pg_basebackup |
Previous Message | Michael Paquier | 2015-11-20 04:16:07 | Re: Confusing error message with too-large file in pg_basebackup |