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

From Andres Freund
Subject Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
Date
Msg-id 20140516191306.GA13967@awork2.anarazel.de
Whole thread Raw
In response to Re: %d in log_line_prefix doesn't work for bg/autovacuum workers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: %d in log_line_prefix doesn't work for bg/autovacuum workers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2014-05-16 14:51:01 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: chr() is still too loose about UTF8 code points
Next
From: Tom Lane
Date:
Subject: Re: btree_gist macaddr valgrind woes