Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) - Mailing list pgsql-hackers

From Jan Urbański
Subject Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
Date
Msg-id 4D6E4653.7070501@wulczer.org
Whole thread Raw
In response to Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
List pgsql-hackers
On 02/03/11 14:25, Robert Haas wrote:
> On Wed, Mar 2, 2011 at 6:14 AM, Jan Urbański <wulczer@wulczer.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
Next
From: Robert Haas
Date:
Subject: Re: Sync Rep v17