Re: It's June 1; do you know where your release is? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: It's June 1; do you know where your release is?
Date
Msg-id 7788.1244051161@sss.pgh.pa.us
Whole thread Raw
In response to Re: It's June 1; do you know where your release is?  (Josh Berkus <josh@agliodbs.com>)
Responses Re: It's June 1; do you know where your release is?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> More suggested dispositions:

>      * contrib/seg and contrib/cube GiST index support have performance issues

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

I might be mistaken, but I think that any fix would invalidate existing
indexes of these types; which would make it problematic to apply a fix
in a minor release.  This item is actually my single biggest concern
of the Open Items list.  I'd really like to see it resolved.  It's not
so much that seg and cube themselves are a big deal, as that I think
people have copied that logic in custom opclasses.  We need to be
shipping an example that's not buggy.

>      * localeconv encoding issues
>            o proposed patch here

> -- Any reason not to apply patch?

It still needs work, per my review the other day.  In any case, it
being a Windows-specific patch, I'd want one of the Windows folk
to take responsibility for testing/committing it --- I'm not going to.

>      * BUG #4622: xpath only work in utf-8 server encoding

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

This resolution is okay with me.  I'm not sure how "major" the
engineering really is, but with no one stepping up to do the work,
I can't see letting this item block the release indefinitely.

>      * autovacuum can run rebuild_database_list unreasonably often

> -- A possible quick workaround would be to put a lower limit of naptime 
> at 1s.

I'm assuming that Alvaro can fix this in a reasonable way as soon as he
gets a little time to spend on it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Managing multiple branches in git
Next
From: Tom Lane
Date:
Subject: Re: It's June 1; do you know where your release is?