Bruce Momjian writes:
Imagine someone always having log_statement on and doing some sort of
aggregate query counting, say like grep '^LOG: query:' | wc -l. Now that
someone (or maybe the admin on the night shift, to make it more dramatic)
also turns on log_min_statement_duration (or
Peter Eisentraut wrote:
Bruce Momjian writes:
Imagine someone always having log_statement on and doing some sort of
aggregate query counting, say like grep '^LOG: query:' | wc -l. Now that
someone (or maybe the admin on the night shift, to make it more dramatic)
also turns on
pgman wrote:
OK, patch attached and applied. Changes are:
query: now statement:
log_duration also now prints when log_min_duration_statement prints
Oh, sample is:
LOG: statement: select 1;
LOG: duration: 0.329 ms
LOG: duration: 0.329 ms statement: select 1;
--
Bruce
Bruce Momjian writes:
Another idea if you like consistency would be:
LOG: duration: 4.056 ms query: select * \nfrom pg_language;
Speaking of consistency...
Imagine someone always having log_statement on and doing some sort of
aggregate query counting, say like grep '^LOG: query:' |
Bruce Momjian writes:
I had a new idea on output format. Instead of converting newline to
\n, and double-escaping backslashes, we add a tab after any newline,
Then how would you identify the real tabs in the data?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
Peter Eisentraut wrote:
Bruce Momjian writes:
Another idea if you like consistency would be:
LOG: duration: 4.056 ms query: select * \nfrom pg_language;
Speaking of consistency...
Imagine someone always having log_statement on and doing some sort of
aggregate query counting,
Bruce Momjian [EMAIL PROTECTED] writes:
Agreed. elog is the proper place, because then you guarantee that it is
all on one line. Is that OK? Do we have elogs that we want over
several lines? Is this something we can do at this stage in beta?
As to the latter: sure. We've already hacked
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Agreed. elog is the proper place, because then you guarantee that it is
all on one line. Is that OK? Do we have elogs that we want over
several lines? Is this something we can do at this stage in beta?
As to the latter: sure.
Bruce Momjian [EMAIL PROTECTED] writes:
Are those lines sent to the elog as one write() or separate ones --- do
they always appear together in the log?
Currently they are sent in a single fprintf(stderr), which might or
might not be good enough to ensure atomicity. We could hack this
to a
On Mon, Oct 06, 2003 at 10:42:57AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I had a new idea on output format. Instead of converting newline to
\n, and double-escaping backslashes, we add a tab after any newline,
That's a thought... seems less invasive than the
Alvaro Herrera Munoz [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
I had a new idea on output format. Instead of converting newline to
\n, and double-escaping backslashes, we add a tab after any newline,
Not good. Some syslogs will replace the literal tab with a ^I.
Tom Lane wrote:
Alvaro Herrera Munoz [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
I had a new idea on output format. Instead of converting newline to
\n, and double-escaping backslashes, we add a tab after any newline,
Not good. Some syslogs will replace the
Tom Lane writes:
Sure it can. You're essentially arguing that DBAs are too dumb to match
up matching query and duration log outputs. I don't buy that. I think
they'll be analyzing their logs with little Perl scripts anyway, and
that consistency of log output format will be worth more to
Tom Lane writes:
I would prefer to see the log entries look like
LOG: query: select * from pg_class;
LOG: duration: nn.nnn msec
I'm not fond of the abbrevation msec or even msecs. The official
abbreviation is ms.
Btw., I was wondering, are we kidding ourselves when we display
Peter Eisentraut wrote:
Tom Lane writes:
Sure it can. You're essentially arguing that DBAs are too dumb to match
up matching query and duration log outputs. I don't buy that. I think
they'll be analyzing their logs with little Perl scripts anyway, and
that consistency of log output
Peter Eisentraut wrote:
Tom Lane writes:
I would prefer to see the log entries look like
LOG: query: select * from pg_class;
LOG: duration: nn.nnn msec
I'm not fond of the abbrevation msec or even msecs. The official
abbreviation is ms.
Yep. Someone suggested msec in
Bruce Momjian wrote:
Btw., I was wondering, are we kidding ourselves when we display
microsecond precision to the user? What accuracy do these measurements
have in respect to what they are actually supposed to measure?
Not sure. I think the microsecond stuff is accurate to some
Peter Eisentraut [EMAIL PROTECTED] writes:
When you're dealing with a large installation, these little Perl scripts
become difficult. I've just had to deal with a similar issue with a
popular MTA which spreads the relevant log information over several lines.
If you're generating 500 MB of log
Bruce Momjian [EMAIL PROTECTED] writes:
Peter, any problems with pid wrap-around? I am thinking we need to
prepend a wrap count on the front of the pid output for 7.5.
Why? And how would you know when the PIDs have wrapped anyway?
The OS already guarantees that no two concurrently running
On Sat, 4 Oct 2003, Tom Lane wrote:
Date: Sat, 04 Oct 2003 15:43:34 -0400
From: Tom Lane [EMAIL PROTECTED]
To: Bruce Momjian [EMAIL PROTECTED]
Cc: Peter Eisentraut [EMAIL PROTECTED], Neil Conway [EMAIL PROTECTED],
PostgreSQL Patches [EMAIL PROTECTED]
Subject: Re: [PATCHES] fix
That was true already with log_statement and log_duration as separate
operations. People use log_pid to deal with it.
Sorry to jump in... the log_pid is NOT ENOUGH where you have more than
3 connections a day (witch is my case)
log_pid isn't enough, but log_pid + log_connections
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
When you're dealing with a large installation, these little Perl scripts
become difficult. I've just had to deal with a similar issue with a
popular MTA which spreads the relevant log information over several lines.
If you're
Patches [EMAIL PROTECTED]
Subject: Re: [PATCHES] fix log_min_duration_statement logic error
That was true already with log_statement and log_duration as separate
operations. People use log_pid to deal with it.
Sorry to jump in... the log_pid is NOT ENOUGH where you have more than
3
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
BTW, EXPLAIN ANALYZE puts out
Total runtime: 406.53 msec
Do you want to make an exception to the string freeze to change this
to ms?
I just realized, all the things that are sent as a query result instead of
an error or notice are
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
BTW, EXPLAIN ANALYZE puts out
Total runtime: 406.53 msec
Do you want to make an exception to the string freeze to change this
to ms?
I just realized, all the things that are sent as a query result instead of
[EMAIL PROTECTED] writes:
Also I'd love to see the log_query being settable per database...
AFAIK you can do that now.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
It is pretty easy to continue pulling lines after the 'duration' hit to
see the full query, perhap using awk, or even grep with a + arg. I just
don't see why we should make it harder for folks by splitting it
Bruce Momjian [EMAIL PROTECTED] writes:
I have not heard from you why we should make it harder (split across two
lines), except for consistency with log_statement and log_duration
outputs.
That is exactly my argument. I'll freely admit that it's not a strong
point, but I find the claim that
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have not heard from you why we should make it harder (split across two
lines), except for consistency with log_statement and log_duration
outputs.
That is exactly my argument. I'll freely admit that it's not a strong
point, but
I have not heard from you why we should make it harder (split across two
lines), except for consistency with log_statement and log_duration
outputs.
I think this is a perfectly good argument. Don't make writing the tools
to parse the log more difficult than necessary.
Rather than making
Rod Taylor wrote:
-- Start of PGP signed section.
I have not heard from you why we should make it harder (split across two
lines), except for consistency with log_statement and log_duration
outputs.
I think this is a perfectly good argument. Don't make writing the tools
to parse the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have not heard from you why we should make it harder (split across two
lines), except for consistency with log_statement and log_duration
outputs.
That is exactly my argument. I'll freely admit that it's not a strong
point, but
have also added code to convert end-of-line characters to \n and \r, and
doubles backslashes. It also makes log_statement print as one line, and
shows pg_stat_activity as one line. Without this fix, you get:
And how does it look with what was originally a fairly readable 30 or 40
line query?
Rod Taylor wrote:
-- Start of PGP signed section.
have also added code to convert end-of-line characters to \n and \r, and
doubles backslashes. It also makes log_statement print as one line, and
shows pg_stat_activity as one line. Without this fix, you get:
And how does it look with
Bruce Momjian [EMAIL PROTECTED] writes:
Another example:
LOG: duration: 4.228 ms; select *\nfrom pg_language;
Minor quibble: would it read better as
LOG: duration n.nnn ms: query
or
LOG: duration n.nnn ms for query
regards, tom lane
Bruce Momjian [EMAIL PROTECTED] 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
Probably pretty long. I think the pg_stat_activity case really needs
the \n because if not the query breaks the table output format. Not
I was actually thinking exactly the opposite. pg_stat_activity viewed in
pgadmin GUI is going to format the table perfectly fine, but with
everthing on one
Rod Taylor wrote:
-- Start of PGP signed section.
Probably pretty long. I think the pg_stat_activity case really needs
the \n because if not the query breaks the table output format. Not
I was actually thinking exactly the opposite. pg_stat_activity viewed in
pgadmin GUI is going to
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
BTW, EXPLAIN ANALYZE puts out
Total runtime: 406.53 msec
Do you want to make an exception to the string freeze to change this
to ms?
I just realized, all the things that are sent as a query result instead of
The problem with two lines is that another log message could get between
them. I agree milliseconds makes more sense for output.
That's not a huge problem. I've run our servers like that for ages, and
there's not really any time when a human can't tell what's going on.
You can also turn on PID
Bruce Momjian writes:
Thanks Peter. Patch attached. I added (secs) to the ouput:
LOG: duration(secs): 0.000257
LOG: duration(secs): 0.000754
LOG: duration(secs): 0.008115 select * from pg_class;
I think the units typically go after the number.
--
Peter Eisentraut
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
LOG: duration(secs): 0.000257
LOG: duration(secs): 0.000754
LOG: duration(secs): 0.008115 select * from pg_class;
I think the units typically go after the number.
In any case, this is unnecessarily incompatible with
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I would prefer to see the log entries look like
LOG: query: select * from pg_class;
LOG: duration: nn.nnn msec
The problem with two lines is that another log message could get between
them.
That was true already with log_statement
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I would prefer to see the log entries look like
LOG: query: select * from pg_class;
LOG: duration: nn.nnn msec
The problem with two lines is that another log message could get between
them.
That was true
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The reason we
needed to do it this way was so we could print the statement _after_ it
completes so we could include the duration.
The behavior I had in mind was to dump the statement at the end of the
query if (a) the duration
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think they fit pretty nicely on one line, and lot of folks want that
information. I realize it looks like bloatware because it duplicates
some existing functionality, but I think it is a combination of duration
and statement
Bruce Momjian writes:
I think there should be just one duration: nnn log entry, printed if
either condition holds.
Done.
Now, if I have log_statement and log_duration on, it logs each statement
twice. The documentation says this:
log_duration (boolean)
Causes the duration of every
Thanks Peter. Patch attached. I added (secs) to the ouput:
LOG: duration(secs): 0.000257
LOG: duration(secs): 0.000754
LOG: duration(secs): 0.008115 select * from pg_class;
---
Peter
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
I also don't particularly like the format of the log message (for one
thing, the duration_statement prefix in the log message shouldn't
include an underscore, it's not a variable or anything -- and the case
can be made that if we
Tom Lane writes:
Neil Conway [EMAIL PROTECTED] writes:
I also don't particularly like the format of the log message (for one
thing, the duration_statement prefix in the log message shouldn't
include an underscore, it's not a variable or anything -- and the case
can be made that if we
Yes, I will.
---
Peter Eisentraut wrote:
Tom Lane writes:
Neil Conway [EMAIL PROTECTED] writes:
I also don't particularly like the format of the log message (for one
thing, the duration_statement prefix in the
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Neil Conway wrote:
This patch fixes an
I think there should be just one duration: nnn log entry, printed if
either condition holds.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
Neil Conway [EMAIL PROTECTED] writes:
I also don't particularly like the format of the log message (for one
thing, the duration_statement prefix in the log message shouldn't
include an underscore, it's not a variable or anything -- and the case
can be made that if we printed the duration
54 matches
Mail list logo
