Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jan Urbański <wulczer@wulczer.org>
Cc: Robert Haas <robertmhaas@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Date: 2011-03-02T15:28:00Z
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 →
-
Further refine patch for commenting operator implementation functions.
- 908ab8028640 9.1.0 cited
-
Fix citext's upgrade-from-unpackaged script to set its collation correctly.
- 94be9e3f0ca9 9.1.0 cited
-
Mark operator implementation functions as such in their comments.
- 94133a935414 9.1.0 cited
-
Add KNNGIST support to contrib/btree_gist.
- 8436489c81c2 9.1.0 cited
-
Fix plpython breakage detected on certain Fedora machines on buildfarm.
- 4c966d920fb7 9.1.0 cited
=?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. regards, tom lane