Re: command tag logging

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: alvherre <alvherre(at)commandprompt(dot)com>
Cc: Ray Stell <stellr(at)cns(dot)vt(dot)edu>, pgsql-admin <pgsql-admin(at)postgresql(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: command tag logging
Date: 2010-05-27 17:15:25
Message-ID: 4083.1274980525@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

alvherre <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of jue may 27 12:49:49 -0400 2010:
>> That is in the right place, isn't it. That would suggest that
>> get_ps_display() is returning a wrong length on Ray's machine.
>> It works okay here, but since that's platform-specific code that
>> hardly proves much. Ray, what platform is this exactly?

> FWIW it fails for me too (Debian running Linux 2.6.32).

Hmm. It seems like the %.*s change could only have affected things if
the PS display area contains \0 characters before the theoretical end
of the string. Which it shouldn't, once we've set the display, but
Ray is only reporting this for log_connection output which might come
out before that.

In any case it strikes me that get_ps_display() is designed on the
assumption that it needn't be particularly fast, but using its result
in log_line_prefix is a place in which performance could indeed matter.
Maybe we should go to some effort to track the intended display string
length explicitly so we could avoid the mucking about in
get_ps_display().

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Ray Stell 2010-05-27 17:25:47 Re: command tag logging
Previous Message alvherre 2010-05-27 16:59:17 Re: command tag logging

Browse pgsql-hackers by date

  From Date Subject
Next Message Ray Stell 2010-05-27 17:25:47 Re: command tag logging
Previous Message Tom Lane 2010-05-27 16:59:49 Re: functional call named notation clashes with SQL feature