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

From Tom Lane
Subject Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
Date
Msg-id 17138.1400263364@sss.pgh.pa.us
Whole thread Raw
In response to %d in log_line_prefix doesn't work for bg/autovacuum workers  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: %d in log_line_prefix doesn't work for bg/autovacuum workers  (Andres Freund <andres@2ndquadrant.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: %d in log_line_prefix doesn't work for bg/autovacuum workers
Next
From: Andres Freund
Date:
Subject: Re: %d in log_line_prefix doesn't work for bg/autovacuum workers