Re: [PATCHES] serverlog function (log_destination file) - Mailing list pgsql-hackers

From Andreas Pflug
Subject Re: [PATCHES] serverlog function (log_destination file)
Date
Msg-id 40CA0295.3030102@pse-consulting.de
Whole thread Raw
In response to Re: [PATCHES] serverlog function (log_destination file)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] serverlog function (log_destination file)
List pgsql-hackers
Tom Lane wrote:

>
>This has got portability issues (fopen("ab"))
>
My doc says b is ignored on ansi systems, and recommends using it. Do
you have other experiences?

> and I don't care for its
>use of malloc in preference to palloc either.
>
Do we already have an applicable memory context in the postmaster at
that early stage of initialization?

>Also, pg_logfile() will dump core if LogFileName returns null.
>
>
How that?

char *filename=LogFileName();
if (filename)
{
       ...
     free(filename);
}

>The bigger issue though is whether this is useful at all, if you cannot
>solve the file rotation issue (and I don't think you can).  As
>implemented, the secondary log file cannot be truncated without
>restarting the postmaster.  I think that reduces it from a possibly
>useful feature to a useless toy.
>
This patch isn't trying to be better on logfile handling than the
default stderr redirection behavior, besides being able to access it
through the postmaster. Seems you insist to name this a toy, many users
don't.

> (The fact that pg_logfile_length
>returns int and not something wider is pretty silly in this connection.)
>
>
2GB logfile seems pretty big...

Regards,
Andreas


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] serverlog function (log_destination file)
Next
From: pgsql@mohawksoft.com
Date:
Subject: Re: msession for PostgreSQL?