Please reply to the list, not just to me.
On 25/07/11 12:33, Harshitha S wrote:
I want to retain all the error messages, error report that is used by Postgres.
I don't intend to log any information extra other than what is provided by Postgres.
But I just want to replace the implementation of the logging/tracing in Postgres, so that the existing messages can be redirected to a file, a USB etc.,
OK. If you are running on Unix/Linux you can just tell your syslog daemon to do that for you, there's no need to modify PostgreSQL at all. See the log_destination parameter in postgresql.conf .
http://www.postgresql.org/docs/current/static/runtime-config-logging.html I don't think syslog is supported on Windows, but you can send logs to "eventlog" to have them recorded into the standard Windows event log. If that's not suitable for you, then I'd recommend that you look at how the log_destination parameter is implemented (look at the "syslog" and "eventlog" implementations) then write your own that sends log events to your custom logging handler. Both of those appear to be implemented in elog.c so you could just copy how one of them works.
Personally, I would STRONGLY recommend using syslog if possible, so you don't have to update your own funky logging support when each new version comes out. If you can't use syslog - say, because you have to use Windows - I'd probably implement a tcp and/or udp syslog backend for PostgreSQL and have my log collector just accept regular network syslog messages.
You should probably implement the udp (and maybe also tcp) syslog protocol if you're going to write your own logging backend, because it's very widely understood and supported by lots of existing logging systems. Then you could have your custom logging system accept network syslog messages from postgresql. The reason to do it this way is simple: network syslog support would be useful to other people, especially on Windows, so if you did a good job your changes might get accepted into PostgreSQL for others to use. They'd be in each release automatically and you wouldn't need to keep on updating them. There is zero chance of a logging implementation for your own non-standard log system getting accepted, which is why you should implement the syslog udp and/or tcp protocols if you're going to roll your own.
For a specification of the syslog network protocols, see these RFCs:
Syslog over UDP
http://tools.ietf.org/html/rfc5426 Syslog over TCP
http://www.ietf.org/rfc/rfc3195.txt --
Craig Ringer