Re: logging stuff
On Tue, 5 Aug 2003, Andrew Dunstan wrote:
(Responding to the deafening silence regarding my posts a couple of days
ago about logging dbnames and disconnections) ;-)The dbname patch is now done. If nobody objects to the format
("[db:yourdbname]") I'll submit it - I did it that way to make it fairly
easy to split a log file based on it, although you would have to be
careful with multiline log entries such as query strings. It is
intentionally minimalist.I had some thoughts about logging disconnections - I can see a way to do
it via an on_proc_exit handler, I think. Then I started wondering if it
might be useful to log session times instead of just noting a disconnect
and letting the user have to calculate the time.But I won't bother with this if there's no interest. *I* have no current
use for it, but I could well imagine others might. (I might too in the
future if I wanted to debug my connection pooling app).
Actually, I'd certainly like to see it done (both dbname and disconnect).
I'd guess the deafening silence was more because of no objctions than lack
of interest. I know for me it was.
Import Notes
Reply to msg id not found: 3F2FD90F.808@dunslane.net
I think we need a more general variable that can take several values,
separated by commas, like:
log_line: dbname,user
or something like that.
In fact, looking at the postgresql.conf file, I see only two setting
that print on every line: log_pid and log_timestamp. Perhaps those two
should be merged into log_line.
Of course, this is all for 7.5.
---------------------------------------------------------------------------
scott.marlowe wrote:
On Tue, 5 Aug 2003, Andrew Dunstan wrote:
(Responding to the deafening silence regarding my posts a couple of days
ago about logging dbnames and disconnections) ;-)The dbname patch is now done. If nobody objects to the format
("[db:yourdbname]") I'll submit it - I did it that way to make it fairly
easy to split a log file based on it, although you would have to be
careful with multiline log entries such as query strings. It is
intentionally minimalist.I had some thoughts about logging disconnections - I can see a way to do
it via an on_proc_exit handler, I think. Then I started wondering if it
might be useful to log session times instead of just noting a disconnect
and letting the user have to calculate the time.But I won't bother with this if there's no interest. *I* have no current
use for it, but I could well imagine others might. (I might too in the
future if I wanted to debug my connection pooling app).Actually, I'd certainly like to see it done (both dbname and disconnect).
I'd guess the deafening silence was more because of no objctions than lack
of interest. I know for me it was.---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
It's more work for a very small cosmetic benefit, ISTM. Setting up
atomic GUC variables is trivially easy, I'm happy to say. Not that I
can't write a simple parser, but why bother for something so tiny?
Also, would we be saying (or implying) that the order given on the line
would affect the output? If so, that could make LOTS more work, again
for very small benefit, I think.
(Yes, of course this is for 7.5).
cheers
andrew
Bruce Momjian wrote:
Show quoted text
I think we need a more general variable that can take several values,
separated by commas, like:log_line: dbname,user
or something like that.
In fact, looking at the postgresql.conf file, I see only two setting
that print on every line: log_pid and log_timestamp. Perhaps those two
should be merged into log_line.Of course, this is all for 7.5.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I think we need a more general variable that can take several values,
separated by commas, like:
log_line: dbname,user
or something like that.
Strikes me as overkill --- adding two more booleans comparable to
log_pid would do the job just as well with lots less coding effort.
regards, tom lane