On 2014-05-16 15:44:53 -0400, Tom Lane wrote:
> 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.
Even the name of the database connected to? I've never checked but I had
assumed it be valid in that database's encoding. But evidently not...
Why doesn't name_text() have to do an encodign check btw? As there
doesn't seem to be much input checking in namein it's a pretty easy way
to get bogus data in.
> 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.
I've tested it here. From what it looks like it prints just fine but
misjudges the width for padding.
> > 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.
You propose to revert?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services