From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Rod Taylor <rbt(at)rbt(dot)ca>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: fix log_min_duration_statement logic error |
Date: | 2003-10-05 21:25:43 |
Message-ID: | 14994.1065389143@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> It is hard to understand how a tool would grab the query from the above
> log except to look for another TAG: entry and stop there.
That was pretty much the centerpiece of my complaint --- up to now it's
been tremendously difficult to parse the PG logs automatically, and I
think something along this line would make it much easier.
I am inclined to think though that Bruce has done this in the wrong
place. If we are going to try to enforce "no real newlines inserted as
part of logged strings", then it ought to be done at a low level in
elog.c where it will apply to *everything* that goes into the log, not
just log_statement/log_duration. For example, we presently allow
embedded newlines in DETAIL/HINT messages, which is fine for frontend
messages but helps to render the log unparsable. Those should be
\n-ified too if we are really interested in making the log easy to
process.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-10-05 21:30:52 | Re: fix log_min_duration_statement logic error |
Previous Message | Bruce Momjian | 2003-10-05 21:19:39 | Re: Open 7.4 items |