From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 05:25:24 |
Message-ID: | CAB7nPqSzp1Z3vEzLyT=79xdiCf2mctSj8CpV1bRje+=ghmTQ0w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Nov 20, 2015 at 1:41 PM, Tom Lane wrote:
> 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.
We could try to have some filtering with the core file name for most
of the main distribution cases, like "core", or "core*", however with
kernel.core_pattern it is easy to set up on a given system a custom
core file name format.
Without having to call "file" through system(), another way would be
to have directly a look at the file type, but this looks
unmaintainable to me, look for example here in magic/Magdir/ that
keeps a reference of that. That's quite interesting.
ftp://ftp.astron.com/pub/file/
Now there is actually the possibility to call directly "file" in the
base backup code path as well, and filter the result depending on if
"core" shows up...
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Lelarge | 2015-11-20 07:39:05 | Re: Confusing error message with too-large file in pg_basebackup |
Previous Message | Tom Lane | 2015-11-20 04:41:34 | Re: Confusing error message with too-large file in pg_basebackup |