Horton

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

Jan Urbański <wulczer@wulczer.org>

View thread
From: Jan Urbański <wulczer@wulczer.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Date: 2011-03-02T15:43:31Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Further refine patch for commenting operator implementation functions.

  2. Fix citext's upgrade-from-unpackaged script to set its collation correctly.

  3. Mark operator implementation functions as such in their comments.

  4. Add KNNGIST support to contrib/btree_gist.

  5. Fix plpython breakage detected on certain Fedora machines on buildfarm.

On 02/03/11 16:28, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <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