Re: 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:
> 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 <http://www.postgresql.org/docs/9.0/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(at)postnewspapers(dot)com(dot)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/