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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
Date: 2014-05-16 18:51:01
Message-ID: 19222.1400266261@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-05-16 18:53:07 Re: chr() is still too loose about UTF8 code points
Previous Message David G Johnston 2014-05-16 18:07:47 Re: chr() is still too loose about UTF8 code points