Re: [PATCHES] [HACKERS] serverlog function (log_destination file)

[Andreas Pflug]

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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
              http://www.postgresql.org/docs/faqs/FAQ.html