Re: %d in log_line_prefix doesn't work for bg/autovacuum workers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
Date
Msg-id 21619.1400269493@sss.pgh.pa.us
Whole thread Raw
In response to Re: %d in log_line_prefix doesn't work for bg/autovacuum workers  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-05-16 14:51:01 -0400, Tom Lane wrote:
>> Ah, you're right, so sprintf shouldn't attempt to truncate the data
>> anywhere.  Nonetheless, this has created a hazard that wasn't there
>> before: with any padding spec, sprintf has to determine the
>> width-in-characters of the supplied string.

> Shouldn't we already have setup the correct locale at that point beside
> a couple of lines inside InitPostgres()?

Define "correct locale".  Keep in mind that names in shared catalogs
might be in any encoding.  But according to previous research, we don't
really guarantee that glibc thinks the encoding is what we think, anyway.
The commit messages for 54cd4f04576833abc394e131288bf3dd7dcf4806 and
ed437e2b27c48219a78f3504b0d05c17c2082d02 are relevant here.  The second
one suggests that only "%.*s" is at risk not "%*s", but I'm not really
convinced right now.  My recollection is that glibc will abandon
processing either format spec if it thinks the string is wrongly encoded.

> Since this is just about things like database,user, application name,
> not the actual log message it's probably not too bad if that
> happens.

[ shrug... ]  People *will* complain if data disappears from their logs.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: btree_gist macaddr valgrind woes
Next
From: Andres Freund
Date:
Subject: Re: %d in log_line_prefix doesn't work for bg/autovacuum workers