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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
Дата
Msg-id 21619.1400269493@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: %d in log_line_prefix doesn't work for bg/autovacuum workers  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: btree_gist macaddr valgrind woes
Следующее
От: Andres Freund
Дата:
Сообщение: Re: %d in log_line_prefix doesn't work for bg/autovacuum workers