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 | 17138.1400263364@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | %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: > elog.c's log_line_prefix() processes %d with: > case 'd': > if (MyProcPort) > { > const char *dbname = MyProcPort->database_name; > if (dbname == NULL || *dbname == '\0') > dbname = _("[unknown]"); > if (padding != 0) > appendStringInfo(buf, "%*s", padding, dbname); 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? Not to mention that if glibc has a different idea of the prevailing encoding than we do, it is quite likely to mess up completely. We've been burnt badly enough by use of this coding technique that it should never have been accepted in someplace as critical as elog.c. regards, tom lane
В списке pgsql-hackers по дате отправления: