Re: %d in log_line_prefix doesn't work for bg/autovacuum workers

On 2014-05-16 14:51:01 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-05-16 14:02:44 -0400, Tom Lane wrote:
> >> Not directly related to your gripe, but: where did this "padding" logic
> >> come from, and what prevents it from creating invalidly-encoded output by
> >> means of truncating multibyte characters in the middle?
>
> > Isn't that syntax just the *minimal* width?
>
> 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()?

> If glibc thinks the data is invalid according to *its* idea of the
> prevailing encoding, it will do something we won't like. My
> recollection is it refuses to print anything at all.

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. I.e. still debuggable. The message itself is separately
appended, so it should still go through unhindered.

Nnote that I haven't been involved in the feature and haven't thought
much about related issues...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services