Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
От | Jan Urbański |
---|---|
Тема | Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) |
Дата | |
Msg-id | 4D6E65A3.7060103@wulczer.org обсуждение исходный текст |
Ответ на | Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
|
Список | pgsql-hackers |
On 02/03/11 16:28, Tom Lane wrote: > Jan Urbański <wulczer@wulczer.org> writes: >> On 02/03/11 14:25, Robert Haas wrote: >>> 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. > > Yeah, that last point makes me nervous too. A look into the Fedora > repository shows that the python version shipped in F13 is rather > heavily patched: > http://pkgs.fedoraproject.org/gitweb/?p=python.git;a=tree;h=refs/heads/f13/master;hb=refs/heads/f13/master > It's not clear to me which of their changes from a stock build might > be at issue, though, and even less clear whether they introduced a > bug or did something to expose a bug of ours. FWIW I looked at these patches yesterday when I was trying to reproduce the bug, but did not find anything interesting. It's mostly for stuff in the standard library. I haven't tried building Python with all of of these patches though, and did not find an easy way to rebuild a SRPM on a Debian system. I'm also wondering if it can be a 32 vs 64 bit issue?... Jan
В списке pgsql-hackers по дате отправления: