Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Logging - events supported

From: Tim Holloway <mtsinc(at)southeast(dot)net>
To: Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it>
Cc: PostgreSQL Hackers <hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Logging - events supported
Date: 1999-10-24 23:08:24
Message-ID: 38139168.A394A269@southeast.net (view raw or flat)
Thread:
Lists: pgsql-hackers

Massimo Dal Zotto wrote:
> 
...
> > 104 - Server ABEND
>                ^^^^^
> 
> This reminds too much the old IBM dinosaurs. Maybe `crash' is more modern.
> 

My past lies exposed! But that's locale=specific. You can just as easily make it report
"La comedia es finito". Or whatever.

> 
> I suggest also the following things:
> 
> 1)      each log entry should be a single line. This would greatly simplify
>         the automatic processing of log files using standard unix tools,
>         including loading entries into a database table.
> 
> 2)      each entry should be prefixed by a timestamp and the backend pid,
>         more or less like the syslog entries. I suggest the following
>         format, which is the one currently implemented by elog_timestamp()
> 
>         991020.14:29:56.699 [7172] started: host=127.0.0.1 user=dz database=dz
>         991020.14:31:02.723 [7172] query: select * from pg_user
>

Well, again, the format of the log output is under the administrator's control. If you
look at how Apache does it, you'll see the idea. Only the "magic codes" have changed to
reflect the differing types of data.
 
> 3)      the logging level can be changed on-the-fly by sending a SIGHUP to
>         the postmaster and then automatically to all the backends. Currently
>         it reloads the pg_options file, which was originally designed exactly
>         for controlling the debug and log messages without restarting the
>         postmaster and all backends, but it could also reload any other
>         configuration file.
>

This was Tom's suggestion as well. It seems good. Unless something prevents it,
that is how it shall work.

    Thanks,

     Tim Holloway

In response to

Responses

pgsql-hackers by date

Next:From: Byron NikolaidisDate: 1999-10-25 01:09:11
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
Previous:From: Mike MascariDate: 1999-10-24 21:54:56
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group