Re: Postgres server output logfile

He is my very simple solution:

8<---------------------------
/*
 * log2file - send stdin to file opening it and closing it regularly
 */

#include <stdio.h>

FILE *  output;
char    buffer[ BUFSIZ];

int
main( int argc, char * argv[ ])
    {
    if ( argc != 2)
        {
        fprintf( stderr, "Usage: %s <output file>\n", argv[ 0]);
        exit( 1);
        }

    output = fopen(( const char *) argv[ 1], "a+");
    fclose( output);
    if ( output == NULL)
        {
        fprintf( stderr, "%s: cannot write to file: %s", argv[ 0], argv[
1]);
        exit( 2);
        }

    fclose( stderr);
    fclose( stdout);

    while ( ! feof( stdin))
        {
        fgets( buffer, sizeof( buffer), stdin);
        output = fopen(( const char *) argv[ 1], "a+");
        fputs( buffer, output);
        fclose( output);
        }
    exit( 0);
    }
8<------------------------------

In /etc/rc.d/init.d/postgresl

[...]
su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl  -D $PGDATA -p
/usr/bin/postmaster start 2>&1 < /dev/null" |\
      /usr/local/bin/log2file /var/log/postgres &
[...]



Giles Lean wrote:
>
> Tom Lane wrote:
>
> > Unfortunately not.  The recommended procedure for production servers is
> > not to send the postmaster's stdout/stderr directly to a disk file, but
> > to pipe it into some script that rotates the output.  There's a usable
> > script in the Apache distribution, or you can roll your own with little
> > effort. ...
>
> There was some interest in such logging programs a while back, and I
> wrote this one:
>
>     ftp://ftp.nemeton.com.au/pub/src/logwrite-1.0alpha.tar.gz
>
> I've attached a message I sent out when I packaged that up.  I had no
> time back then (2001, yikes) and didn't receive any comments or bug
> reports.
>
> If there is interest now, then I'll update the documentation, format
> the code per the PostgreSQL coding standards and offer it again.
>
> A patch to the postmaster so that it starts the log program and can
> re-start it if someone kills it would improve robustness even further,
> but 'kill -9' on the postmaster is bad, and so is 'kill -9' on the log
> program. :-)
>
> Regards,
>
> Giles
>
>   ------------------------------------------------------------------------
>
> Subject: Re: [HACKERS] Log rotation?
> Date: Sat, 08 Sep 2001 07:21:19 +1000
> From: Giles Lean <giles@nemeton.com.au>
> To: Peter Eisentraut <peter_e@gmx.net>
> CC: PostgreSQL Development <pgsql-hackers@postgresql.org>
>
> Hi Peter,
>
> > I've been playing with a little program I wrote whose sole purpose is to
> > write its stdin to a file and close and reopen that file when it receives
> > a signal.  I figured this could work well when integrated transparently
> > into pg_ctl.
> >
> > So, is log rotation a concern?  Is this a reasonable solution?  Other
> > ideas?
>
> There was a discussion of this over a year ago.  After I contributed
> to the discussion Tom Lane suggested I write something, and in the
> tradition of software development I did so but never quite finished it
> ... I got to the point that it works for me, then got distracted
> before completing a test suite.
>
> You may well prefer your own code, but this one supports rotation on
> size and/or time basis as well as on receipt of SIGHUP, and places a
> timestamp on each line written. It's also pretty careful about errors,
> which is one of the things that was disliked about the Apache program
> last time it was discussed.
>
> I am happy to contribute the code using the standard PostgreSQL
> license if it's wanted.  (If anyone wants it under a BSD license or
> GPL for another purpose that's fine too.)
>
> I use the code on HP-UX, and developed it on NetBSD.  There shouldn't
> be too many portability problems lurking, other than the usual hassles
> of what % escape to use in printf() for off_t.  I doubt anyone wants
> log files larger than a couple of GB anyway? :-)
>
> ftp://ftp.nemeton.com.au/pub/src/logwrite-1.0alpha.tar.gz
>
> > (No Grand Unified Logging Solutions please.  And no, "use syslog" doesn't
> > count.)
>
> <grin>
>
> One improvement I suggest is that the postmaster be taught to start
> (and restart if necessary) the log program.  This avoids fragile
> startup scripts and also avoids taking down PostgreSQL if someone
> sends the wrong signal to the log program.
>
> Cheers,
>
> Giles
>
>   ------------------------------------------------------------------------
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster