VACUUM messages without newlines
This has annoyed me for some time, but it appears that in the VACUUM
log, the line which says...
INFO: analyzing "%s.%s"
...( and appears in pgsql/src/backend/commands/analyze.c lines 282 and
287 ) doesn't terminate with a newline, meaning the next message
appears immediately after it. Either the errmsg function should be
doing this, or should be included explicitly in the message itself as
it does with all other messages output to VACUUM logs.
The same goes for...
CPU %d.%02ds/%d.%02du sec elapsed %d.%02d sec
... as appearing in pgsql/src/backend/utils/misc/pg_rusage.c (line 64)
and
"%s": scanned %d of %u pages, containing %.0f live rows and %.0f dead
rows; %d rows in sample, %.0f estimated total rows
... in pgsql/src/backend/commands/analyze.c (line 1220).
Could this be changed, or is there a reason these have to be logged this way?
Thanks
Thom
Excerpts from Thom Brown's message of mar jun 01 11:16:33 -0400 2010:
This has annoyed me for some time, but it appears that in the VACUUM
log, the line which says...INFO: analyzing "%s.%s"
...( and appears in pgsql/src/backend/commands/analyze.c lines 282 and
287 ) doesn't terminate with a newline, meaning the next message
appears immediately after it.
The message pieces are sent separately. They are only crammed in a
single line if the interface is using the old mechanism to extract error
message info; anything built after cca. 2002 should be reading fields
separately, and printing them in separate lines.
The same goes for...
CPU %d.%02ds/%d.%02du sec elapsed %d.%02d sec
Now you can argue that this line is too long, but that's a different
problem than the one above.
"%s": scanned %d of %u pages, containing %.0f live rows and %.0f dead
rows; %d rows in sample, %.0f estimated total rows
This too.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 1 June 2010 16:28, Alvaro Herrera <alvherre@commandprompt.com> wrote:
Excerpts from Thom Brown's message of mar jun 01 11:16:33 -0400 2010:
This has annoyed me for some time, but it appears that in the VACUUM
log, the line which says...INFO: analyzing "%s.%s"
...( and appears in pgsql/src/backend/commands/analyze.c lines 282 and
287 ) doesn't terminate with a newline, meaning the next message
appears immediately after it.The message pieces are sent separately. They are only crammed in a
single line if the interface is using the old mechanism to extract error
message info; anything built after cca. 2002 should be reading fields
separately, and printing them in separate lines.
I see what you mean. I'm seeing this in the latest version of pgAdmin
III (1.10.3) so looks like it's not up-to-date in that respect.
Should report it as a pgAdmin problem then?
Thanks
Thom
Thom Brown <thombrown@gmail.com> writes:
I see what you mean. I'm seeing this in the latest version of pgAdmin
III (1.10.3) so looks like it's not up-to-date in that respect.
Should report it as a pgAdmin problem then?
Yes. The message texts in ereport() calls are *not* supposed to have
trailing newlines. If you don't like the way it's presented on the
client side, that's a client-side problem.
regards, tom lane
On 1 June 2010 16:50, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thom Brown <thombrown@gmail.com> writes:
I see what you mean. I'm seeing this in the latest version of pgAdmin
III (1.10.3) so looks like it's not up-to-date in that respect.
Should report it as a pgAdmin problem then?Yes. The message texts in ereport() calls are *not* supposed to have
trailing newlines. If you don't like the way it's presented on the
client side, that's a client-side problem.regards, tom lane
Yes, I can see that now. I'd looked up other messages which appear in
the log and noticed they were terminated with newlines in the
back-end, but I guess those were of a different type and happen to
share the same output.
Thanks
Thom
Excerpts from Thom Brown's message of mar jun 01 11:34:38 -0400 2010:
On 1 June 2010 16:28, Alvaro Herrera <alvherre@commandprompt.com> wrote:
The message pieces are sent separately. They are only crammed in a
single line if the interface is using the old mechanism to extract error
message info; anything built after cca. 2002 should be reading fields
separately, and printing them in separate lines.I see what you mean. I'm seeing this in the latest version of pgAdmin
III (1.10.3) so looks like it's not up-to-date in that respect.
Should report it as a pgAdmin problem then?
Hmm, I wouldn't expect pgAdmin to behave this way.
[ tests ... ]
Hey, I see a problem here. After the last INFO message (which is not
the same you mentioned, at least in this server version) my server
crashed for whatever reason, and the error report for that got stuffed
in the same line, and it didn't have the FATAL leader either. Pretty
weird. I'm fairly sure this is pgAdmin's doing, 'cause psql doesn't
behave this way.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Thom Brown <thombrown@gmail.com> writes:
Yes, I can see that now. I'd looked up other messages which appear in
the log and noticed they were terminated with newlines in the
back-end, but I guess those were of a different type and happen to
share the same output.
Hm, sure you're not thinking of frontend code? We generally do include
trailing newlines in message texts on that side, but elog/ereport on
the backend side should never have them.
regards, tom lane