From: | Jan Urbański <wulczer(at)wulczer(dot)org> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) |
Date: | 2011-03-02 13:29:55 |
Message-ID: | 4D6E4653.7070501@wulczer.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/03/11 14:25, Robert Haas wrote:
> On Wed, Mar 2, 2011 at 6:14 AM, Jan Urbański <wulczer(at)wulczer(dot)org> wrote:
>>> That seems to have fixed it, so I have applied the patch. Would you like
>>> to supply some comments to got with it?
>>
>> The comment would be something like
>>
>> /* XXX it appears that in some circumstantes the reference count of the
>> spiexceptions module drops to zero causing a Python assert failure when
>> the garbage collector visits the module. This has been observed on the
>> buildfarm. To fix this, add an additional ref for the module here. */
>>
>> I have no idea why the refcount of the module becomes zero, debug prints
>> I added on my system were always showing 1.
>
> But does bumping the ref count then create a leak the rest of the time?
Not really, because you never want to garbage collect the spiexceptions
module (just like you don't want to GC th plpy module, or the plpy.info
function etc.). So the reference count of that module should never drop
to zero, but apparently on some machines it does. So just reffing
artificailly is kind of a valid solution, I'm just uneasy with not
knowing why it fails on some machines and does not on others.
Jan
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-03-02 14:30:42 | Re: Sync Rep v17 |
Previous Message | Robert Haas | 2011-03-02 13:28:43 | Re: Sync Rep v17 |