Prev: [HACKERS] VACUUM messages without newlines
Next: [HACKERS] CommitFest FAQ (was: dividing money by money)
From: Alvaro Herrera on 1 Jun 2010 11:28 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 1 Jun 2010 11:34 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 1 Jun 2010 11:50 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 1 Jun 2010 11:59 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 1 Jun 2010 12:00 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
|
Next
|
Last
Pages: 1 2 Prev: [HACKERS] VACUUM messages without newlines Next: [HACKERS] CommitFest FAQ (was: dividing money by money) |