From: Alvaro Herrera on
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(a)commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Thom Brown on
On 1 June 2010 16:28, Alvaro Herrera <alvherre(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on
Thom Brown <thombrown(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Thom Brown on
On 1 June 2010 16:50, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Thom Brown <thombrown(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Alvaro Herrera on
Excerpts from Thom Brown's message of mar jun 01 11:34:38 -0400 2010:
> On 1 June 2010 16:28, Alvaro Herrera <alvherre(a)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(a)commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers