Re: debug log in pg_archivecleanup

Hi,

Sometimes the postgres server log message and the pg_archivecleanup debug
message are output in the same line as follows. This is a little hard to
read.

-----------------------
LOG: restored log file "00000001000000000000006B" from archive
pg_archivecleanup: keep WAL file 000000010000000000000068 and later
pg_archivecleanup: removing
"/dav/head-pgsql/act.arh/000000010000000000000048"LOG: restored log
file "00000001000000000000006C" from archive

pg_archivecleanup: removing "/dav/head-pgsql/act.arh/000000010000000000000061"
pg_archivecleanup: removing "/dav/head-pgsql/act.arh/00000001000000000000004D"
pg_archivecleanup: removing "/dav/head-pgsql/act.arh/00000001000000000000005C"
-----------------------

This is because pg_archivecleanup puts the line break "\n" in the head of
debug message. Why should we do so?

-----------------------
if (debug)
fprintf(stderr, "\n%s: removing \"%s\"", progname, WALFilePath);
-----------------------

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> This is because pg_archivecleanup puts the line break "\n" in the head of
> debug message. Why should we do so?
>
> -----------------------
> if (debug)
> fprintf(stderr, "\n%s: removing \"%s\"", progname, WALFilePath);
> -----------------------

We also need "\n" at line 308.
L.125: fprintf(stderr, "\n%s: removing \"%s\"", progname, WALFilePath);
L.308: fprintf(stderr, "%s: keep WAL file %s and later", progname, exclusiveCleanupFileName);

Note that we don't need a line break at Line 130
because strerror() fills the last %s.
L.130: fprintf(stderr, "\n%s: ERROR failed to remove \"%s\": %s",

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center

On Wed, Jun 16, 2010 at 12:24 PM, Takahiro Itagaki
<itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
>
> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
>> This is because pg_archivecleanup puts the line break "\n" in the head of
>> debug message. Why should we do so?
>>
>> -----------------------
>>  if (debug)
>>     fprintf(stderr, "\n%s:  removing \"%s\"", progname, WALFilePath);
>> -----------------------
>
> We also need "\n" at line 308.
>  L.125: fprintf(stderr, "\n%s:  removing \"%s\"", progname, WALFilePath);
>  L.308: fprintf(stderr, "%s:  keep WAL file %s and later", progname, exclusiveCleanupFileName);

Yes. What about the attached patch?

> Note that we don't need a line break at Line 130
> because strerror() fills the last %s.
>  L.130: fprintf(stderr, "\n%s: ERROR failed to remove \"%s\": %s",

Right.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> On Wed, Jun 16, 2010 at 12:24 PM, Takahiro Itagaki
> <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
>> This is because pg_archivecleanup puts the line break "\n" in the head of
>> debug message. Why should we do so?

> Yes. What about the attached patch?

Applied along with a bit of further editorialization.

>> Note that we don't need a line break at Line 130
>> because strerror() fills the last %s.
>> L.130: fprintf(stderr, "\n%s: ERROR failed to remove \"%s\": %s",

> Right.

Huh? strerror() doesn't include a newline.

regards, tom lane

On Thu, 2010-06-17 at 13:33 -0400, Tom Lane wrote:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> > On Wed, Jun 16, 2010 at 12:24 PM, Takahiro Itagaki
> > <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> >> This is because pg_archivecleanup puts the line break "\n" in the head of
> >> debug message. Why should we do so?
>
> > Yes. What about the attached patch?
>
> Applied along with a bit of further editorialization.
>
> >> Note that we don't need a line break at Line 130
> >> because strerror() fills the last %s.
> >> L.130: fprintf(stderr, "\n%s: ERROR failed to remove \"%s\": %s",
>
> > Right.
>
> Huh? strerror() doesn't include a newline.

Thanks.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services