From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 20:30:59 |
Message-ID: | 20140516203059.GD13967@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-05-16 16:19:28 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-05-16 15:44:53 -0400, Tom Lane wrote:
> >> 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.
>
> > I've tested it here. From what it looks like it prints just fine but
> > misjudges the width for padding.
>
> Oh, good. We can live with that.
Yea, seems pretty harmless. It's a pretty new glibc version though, so
things might have been different in the past. On the other hand I can
see more justification to stop processing on input than output...
> (In any case, we could retain the feature and just do the padding
> computations ourselves. But I now think we don't have to.)
Might actually make the code somewhat less ugly... But I am not
volunteering.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Singer | 2014-05-16 20:37:16 | CREATE REPLICATION SLOT fails on a timeout |
Previous Message | Tom Lane | 2014-05-16 20:19:28 | Re: %d in log_line_prefix doesn't work for bg/autovacuum workers |