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 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