Thread: 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