Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
От | Tom Lane |
---|---|
Тема | Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4) |
Дата | |
Msg-id | 17404.1357940971@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4) (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree
mulation (was xlogreader-v4)
|
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2013-01-11 16:28:13 -0500, Tom Lane wrote: >> I'm not very satisfied with that answer. Right now, Peter's >> patch has added a class of bugs that never existed before 9.3, and yours >> would add more. It might well be that those classes are empty ... but >> *we can't know that*. I don't think that keeping a new optimization for >> non-gcc compilers is worth that risk. Postgres is already full of >> gcc-only optimizations, anyway. > ISTM that ereport() already has so strange behaviour wrt evaluation of > arguments (i.e doing it only when the message is really logged) that its > doesn't seem to add a real additional risk. Hm ... well, that's a point. I may be putting too much weight on the fact that any such bug for elevel would be a new one that never existed before. What do others think? regards, tom lane
В списке pgsql-hackers по дате отправления: