From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | John R Pierce <pierce(at)hogranch(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Confusing error message with too-large file in pg_basebackup |
Date: | 2015-11-21 05:16:56 |
Message-ID: | CAB7nPqThD70_X0xUHwrVo4kYUXndgmxJ1uoP7eB2T36UWsLpBg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, Nov 21, 2015 at 7:34 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> John R Pierce <pierce(at)hogranch(dot)com> writes:
>> On 11/20/2015 2:13 PM, Tom Lane wrote:
>>> It'd be reasonable to skip 'em if we can identify 'em reliably. I'm
>>> not sure how reliably we can do that though.
>
>> aren't they nearly always named 'core' ?
>
> No. Modern systems more often call them something like 'core.<pid>'.
> What really makes it messy is that the name is user-configurable on
> most Linux kernels, see /proc/sys/kernel/core_pattern.
>
> We could probably get away with excluding anything that matches "*core*",
> but it wouldn't be bulletproof.
It does not look like a good idea to me. I have no doubts that there
are deployments including configuration files with such abbreviations
in PGDATA.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | David Gould | 2015-11-21 10:52:16 | Re: Confusing error message with too-large file in pg_basebackup |
Previous Message | Tom Lane | 2015-11-21 01:54:50 | Re: Confusing error message with too-large file in pg_basebackup |