Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)

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

In response to

Responses

Browse pgsql-hackers by date

  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