Обсуждение: Tracing in Postgres
Hi,
I am trying to integrate a tracing framework in the Postgres code.
I need to know if elog.c under backend/utils/error is the place where the changes can be made.
The tracing framework that I want to integrate has some additional capability. I want to replace the tracing and logging functionality in the existing Postgres framework with the APIs used in this framework without making changes in every file.
If anybody has any inputs on this, please help me.
Thanks,
Harshitha
On 22/07/2011 4:43 PM, Harshitha S wrote: > Hi, > I am trying to integrate a tracing framework in the Postgres code. > I need to know if elog.c under backend/utils/error is the place where > the changes can be made. It depends: what exactly are the kinds of events you want to trace? If you're looking to redirect the logging output Pg can already produce, you can just have your tracing system act as a syslog daemon and get postgresql to write to syslog. If you want something more detailed, elog will probably do much of what you need. If you want to trace things like actual row changes, which Pg never writes through elog, you won't be able to get them via that mechanism. -- Craig Ringer POST Newspapers 276 Onslow Rd, Shenton Park Ph: 08 9381 3088 Fax: 08 9388 2258 ABN: 50 008 917 717 http://www.postnewspapers.com.au/
Please reply to the list, not just to me.
On 25/07/11 12:33, Harshitha S wrote:
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
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
Craig Ringer <craig@postnewspapers.com.au> writes:
> On 25/07/11 12:33, Harshitha S wrote:
>> 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.
Or just redirect postmaster's stderr to the target file, and don't even
bother with syslog ...
regards, tom lane
On 25/07/2011 9:54 PM, Tom Lane wrote: > Or just redirect postmaster's stderr to the target file, and don't even > bother with syslog ... > True. I was working on the assumption that the OP wanted to change the output destination at runtime, but if that is not the case then a simple redirect is a no-brainer. -- Craig Ringer POST Newspapers 276 Onslow Rd, Shenton Park Ph: 08 9381 3088 Fax: 08 9388 2258 ABN: 50 008 917 717 http://www.postnewspapers.com.au/