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:02:44 |
Message-ID: | 17138.1400263364@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:
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-05-16 18:06:36 | Re: %d in log_line_prefix doesn't work for bg/autovacuum workers |
Previous Message | Andres Freund | 2014-05-16 17:54:56 | %d in log_line_prefix doesn't work for bg/autovacuum workers |