From: | Jan Urbański <wulczer(at)wulczer(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Potential reference miscounts and segfaults in plpython.c |
Date: | 2012-02-20 10:05:43 |
Message-ID: | 4F421AF7.1080308@wulczer.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20/02/12 04:29, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer(at)wulczer(dot)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).
Cheers,
Jan
From | Date | Subject | |
---|---|---|---|
Next Message | Itagaki Takahiro | 2012-02-20 12:30:13 | array_to_json re-encodes ARRAY of json type |
Previous Message | Simon Riggs | 2012-02-20 09:18:44 | Re: 16-bit page checksums for 9.2 |