Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 5487663362A for ; Tue, 2 Jun 2009 21:27:31 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 95574-01-3 for ; Tue, 2 Jun 2009 21:27:27 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from glacier.frostconsultingllc.com (glacier.frostconsultingllc.com [69.36.227.170]) by mail.postgresql.org (Postfix) with ESMTP id 32D55635182 for ; Tue, 2 Jun 2009 21:26:29 -0300 (ADT) Received: from dsl081-245-111.sfo1.dsl.speakeasy.net ([64.81.245.111] helo=Sidney-Stratton.local) by glacier.frostconsultingllc.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69) (envelope-from ) id 1MBeJE-0002jZ-1d for pgsql-hackers@postgreSQL.org; Tue, 02 Jun 2009 17:26:26 -0700 Message-ID: <4A25C32F.30203@agliodbs.com> Date: Tue, 02 Jun 2009 17:26:23 -0700 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: PostgreSQL-development Subject: Re: It's June 1; do you know where your release is? References: <19107.1243873940@sss.pgh.pa.us> <603c8f070906012050p6ccd62d3v13d3e0f887fe7c90@mail.gmail.com> <15765.1243965376@sss.pgh.pa.us> In-Reply-To: <15765.1243965376@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200906/259 X-Sequence-Number: 139314 Tom, all, More suggested dispositions: * plperl fails with Perl 5.10 on Windows o tgl says: no reports of this with pre-8.4 Postgres, but I bet that's just because no one tried it o dpage says: I'm rolling back the Windows installers to use 5.8 for now. Would appreciate help from anyone familiar with Perl internals to try to debug this further! -- Dunstan, Wheeler, Sabino-Mullaine, 'lil help please? * contrib/seg and contrib/cube GiST index support have performance issues o proposed (incomplete) patch here -- If it's just a performance issue, I don't think this issue should block 8.4.0; it can be fixed in 8.4.1 if necessary, since we'll probably want to backpatch the fix anyway. * possible bug in cover density ranking? -- From Teodor's response, this is maybe a doc patch and not a code patch. Teodor? Oleg? * localeconv encoding issues o proposed patch here -- Any reason not to apply patch? * BUG #4622: xpath only work in utf-8 server encoding o tgl says: there's a proposed patch for this, but I don't think it fixes it -- I think this is a doc patch. Since libxml (as I understand it) only supports UTF, this is not something we can fix without major engineering anyway, certainly not before release. I just think we need big warnings in the docs in several places. * contrib/intarray opclass definition needs updating o tgl says: done, but there's another problem; see also bug #4806 -- This is a serious issue which I'm not sure how we can resolve in the next couple weeks. Simply throwing a warning is inadequate (although if we can't fix it in time, we'll have to do that). Having the planner refuse to use the index if '{}' is involved is problematic from a performance standpoint. And changing GIN and GiST so they index empty arrays seems likely to have other side effects. Ideas, anyone? * Path separator consistency on Windows -- This discussion does not appear to have concluded. Magnus, Dave? * autovacuum can run rebuild_database_list unreasonably often -- A possible quick workaround would be to put a lower limit of naptime at 1s. This would save most people (those with 10 or less database) from triggering rebuild_database_list too often. However, given that it's precisely the people with 100's of databases who would want to lower naptime to very low levels, this isn't much of a solution. On the other-other hand, this is enough of a corner case that I think we can put in a documentation warning and put a fix for this in the TODO list. Unless Alvaro can get in a patch which prevents rebuild_database_list from running more often than once per minute this week? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com