| 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 20:19:28 |
| Message-ID: | 22334.1400271568@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
> You propose to revert?
Not if the data gets printed. I was afraid it wouldn't be.
(In any case, we could retain the feature and just do the padding
computations ourselves. But I now think we don't have to.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-05-16 20:30:59 | Re: %d in log_line_prefix doesn't work for bg/autovacuum workers |
| Previous Message | Andres Freund | 2014-05-16 20:09:49 | Re: %d in log_line_prefix doesn't work for bg/autovacuum workers |