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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
