Re: It's June 1; do you know where your release is?

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
alsobug 
 
#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
casethat 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