Re: Potential reference miscounts and segfaults in plpython.c
От | Robert Haas |
---|---|
Тема | Re: Potential reference miscounts and segfaults in plpython.c |
Дата | |
Msg-id | CA+TgmoZzk1JNwAGsDH9ohnz0O7j3a=K0U+YOXKViHB1imNNKZg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Potential reference miscounts and segfaults in plpython.c (Jan Urbański <wulczer@wulczer.org>) |
Список | pgsql-hackers |
On Mon, Feb 20, 2012 at 5:05 AM, Jan Urbański <wulczer@wulczer.org> wrote: > On 20/02/12 04:29, Tom Lane wrote: >> 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". >> >> 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? > > AFAICS these errors can only happen on out of memory conditions or other > internal errors (like trying to create a list with a negative length). We typically want out of memory to use ereport, so that it gets translated. For example, in fd.c we have: ereport(FATAL, (errcode(ERRCODE_OUT_OF_MEMORY), errmsg("out of memory"))); Trying to create a list with a negative length sounds similar. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: