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

In response to

Responses

Browse pgsql-hackers by date

  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