From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_archivecleanup bug (invalid filename input) |
Date: | 2015-06-10 12:25:40 |
Message-ID: | CAB7nPqR99rYb_3L6ssByWh1td2ksxXCv=FzR6mpS5-PR9Q6N0w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 10, 2015 at 12:29 PM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>
> On 06/09/2015 05:54 PM, Michael Paquier wrote:
>
>> Looking at the documentation what is expected is not a path to a
>> segment file, but only a segment file name:
>> http://www.postgresql.org/docs/devel/static/pgarchivecleanup.html
>> So the current behavior is correct, it is actually what
>> SetWALFileNameForCleanup(at)pg_archivecleanup(dot)c checks in the code.
>
>
> O.k.... so I would say: Should we adjust this behavior? It seems to me that
> it should accept a path.
Perhaps others have a different opinion, but I don't see much the
point. First, archive_cleanup_command uses %r with only a segment file
name. Then, in the case where pg_archivecleanup is called within a
script and that the segment name is retrieved from a given path that
you may want to append, this script is going to scan this directory to
fetch the segment file name anyway, actually killing the purpose of
appending a path.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2015-06-10 13:18:56 | s_lock() seems too aggressive for machines with many sockets |
Previous Message | Amit Langote | 2015-06-10 12:20:34 | Re: [idea] table partition + hash join |