Thus spake Tim Holloway
> Request For Comments: Towards an industrial-strength
> logging facility
<COMMENT>Woo hoo!</COMMENT>
Yes please. As soon as possible. I have been trying to figure out all
sorts of kluges for this. I even considered putting something in PyGreSQL
but this is mush better.
> Design goals
>
> 1. Robustness. Adding logging should not cause the system to
> become unstable.
Absolutely.
> 2. Performance. Unless you're IBM at least, logging is a
> means, not an end. The performance of the system
> must not be degraded.
If performance takes a hit, could it be turned on and off with a flag
or by the existence of the config file itself? That way people willing
to pay for the logging can and those that need performance above all
can get it.
> Postgres [123] 900 - Logging configuration file
> "/usr/local/pgsql/data/postgresql.conf" was not found or
> denied access. Using default logging.
Or don't log - see above.
The one thing I would suggest is make sure that logs get date and time stamped.
How about the ability to send the log to a process instead of a file? I
would like to log on a separate machine but there is firewall considerations.
> Although this scheme may appear elaborate, the internal
> realization is fairly simple. I have far more concern that
> it may overwhelm someone who is new to the entire PostgreSQL
> system and is FAR more interested at that time in learning
I don't see a problem here. Logging would be an advanced subject. No
one would have to deal with it. I think it is important that it not
log (or log to /dev/null) by default so that new users don't suddenly
find their disk space disappearing. Logging (especially if you log
SELECTs) cand use a lot of space.
Good work. This was definitely needed.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
