Re: Potential reference miscounts and segfaults in plpython.c

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Potential reference miscounts and segfaults in plpython.c
Дата
Msg-id 17954.1329708579@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Potential reference miscounts and segfaults in plpython.c  (Jan Urbański <wulczer@wulczer.org>)
Ответы Re: Potential reference miscounts and segfaults in plpython.c  (Jan Urbański <wulczer@wulczer.org>)
Re: Potential reference miscounts and segfaults in plpython.c  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Jan Urbański <wulczer@wulczer.org> writes:
>> On 18/02/12 21:17, Tom Lane wrote:
>>> Dave Malcolm at Red Hat has been working on a static code analysis tool
>>> for Python-related C code.  He reports here on some preliminary results
>>> for plpython.c:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=795011

> Here's a patch that fixes everything I was sure was an actual bug. The
> rest of the warnings seem to be caused by the tool not knowing that
> elog(ERROR) throws a longjmp and things like "we never unref this
> object, so it can't disappear mid-execution".

This looks pretty sane to me, but it would probably be better if one of
the more python-savvy committers took responsibility for final review.

My only comment is whether elog(ERROR) is appropriate, ie, do we consider
these to be internal errors that users will never see in practice?
If there's a significant risk of the error being thrown in the field,
it might be better to use ereport, to expose the message for
translation.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Future of our regular expression code
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Future of our regular expression code