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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On 1 June 2010 16:28, Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)gmail(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thom Brown <thombrown(at)gmail(dot)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(at)commandprompt(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Thom Brown <thombrown(at)gmail(dot)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