Re: 8.4 open items list

Robert Haas wrote:

On Thu, Mar 26, 2009 at 9:36 PM, Bruce Momjian <bruce@momjian.us> wrote:

I'm sure they will. ?But the current problem is getting beta released
in the first place, and AFAICS we're all waiting for you.

As Tom said, it is more the open items that we are waiting on, not the
release notes, but if if you are waiting for me to generate a list of
open items, I already published in inaccurate list that at least
_includes_ all the open items, plus lots of stuff that isn't open.

Hmm, well, Tom dropped a filtered version of your list into the open
items wiki page.

http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items

That includes a whole slough of patches that weren't submitted until
after November 1st and which I think should probably be bumped en
masse to 8.5:

Change behavior of statement-level triggers for inheritance cases?
GetCurrentVirtualXIDs() (is this patch safe?)
PQinitSSL broken in some use cases
postgresql.conf: patch to have ParseConfigFile report all parsing
errors, then bail
small but useful patches for text search
Additional DTrace Probes
pg_standby trigger behavior is dangerous
psql \d commands and information_schema (already in CommitFest 2009-First)
Have \d show child tables that inherit from the specified parent
(already in CommitFest 2009-First)

Wow, that is a large list. Getting this all on a wiki is really what
needed to happen. I can't keep an open list current enough to be
useful.

I think we should also boot everything in the "pre-existing bugs"
category, and the first two items from the "questions" category, which
don't seem important enough to worry about at this stage of the game.
That would leave us with 14 items, all of which look reasonably
relevant and 8.4-related.

I think pushing "pre-existing bugs" to 8.5 is a mistake, first from a
software quality standpoint, and second because we are going to have a
lots of downtime during beta while we wait for feedback, so we can work
on some of these issues then. These things are not going to be any
easier to fix during 8.5 than now so let's make 8.4 as good as we can
without overly-delaying it.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas <robertmhaas@gmail.com> wrote:

That includes a whole slough of patches that weren't submitted until
after November 1st and which I think should probably be bumped en
masse to 8.5:

postgresql.conf: patch to have ParseConfigFile report all parsing
errors, then bail

Not sure about this one. A similar patch for the pg_hba.conf file
submitted after the commit fest (IIRC) has already been commited.

pg_standby trigger behavior is dangerous

This one has to be fixed IMHO. I'm not sure how but we have to take a
decision. The current behaviour is really dangerous for most of our
users.

--
Guillaume

On Thu, Mar 26, 2009 at 10:11 PM, Bruce Momjian <bruce@momjian.us> wrote:

Hmm, well, Tom dropped a filtered version of your list into the open
items wiki page.

http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items

That includes a whole slough of patches that weren't submitted until
after November 1st and which I think should probably be bumped en
masse to 8.5:

Change behavior of statement-level triggers for inheritance cases?
GetCurrentVirtualXIDs() (is this patch safe?)
PQinitSSL broken in some use cases
postgresql.conf: patch to have ParseConfigFile report all parsing
errors, then bail
small but useful patches for text search
Additional DTrace Probes
pg_standby trigger behavior is dangerous
psql \d commands and information_schema (already in CommitFest 2009-First)
Have \d show child tables that inherit from the specified parent
(already in CommitFest 2009-First)

Wow, that is a large list.  Getting this all on a wiki is really what
needed to happen.  I can't keep an open list current enough to be
useful.

Ah, glad you like. I thought you'd been arguing the other side of
that point with me for several days, but no matter - it seems like we
might be converging on some kind of consensus here.

I think we should also boot everything in the "pre-existing bugs"
category, and the first two items from the "questions" category, which
don't seem important enough to worry about at this stage of the game.
That would leave us with 14 items, all of which look reasonably
relevant and 8.4-related.

I think pushing "pre-existing bugs" to 8.5 is a mistake, first from a
software quality standpoint, and second because we are going to have a
lots of downtime during beta while we wait for feedback, so we can work
on some of these issues then.  These things are not going to be any
easier to fix during 8.5 than now so let's make 8.4 as good as we can
without overly-delaying it.

What is the threshold for "has to be fixed before we can go to beta"
versus "has to be fixed before release"? I'm not opposed to fixing
the bugs, but it seems like every day that we postpone cutting a beta
is one more day until release, and so I think our immediate goal
should be to fix all of the things that need to be fixed before beta
can start.

...Robert

On Thu, Mar 26, 2009 at 11:06 PM, Guillaume Smet
<guillaume.smet@gmail.com> wrote:

On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas <robertmhaas@gmail.com> wrote:

That includes a whole slough of patches that weren't submitted until
after November 1st and which I think should probably be bumped en
masse to 8.5:

postgresql.conf: patch to have ParseConfigFile report all parsing
errors, then bail

Not sure about this one. A similar patch for the pg_hba.conf file
submitted after the commit fest (IIRC) has already been commited.

Well, if we keep slipping one more thing in, we're never going to get
this thing out the door. The fact that we've already let some extra
things slip in is not a good reason to slip in moor things. The patch
may be great stuff and if a committer wants to pick it up and commit
it, that's their prerogative. But to my mind this sounds like an
enhancement, and since we've supposedly been in feature freeze for
almost 5 months, I see no reason to argue that it MUST happen before
beta.

pg_standby trigger behavior is dangerous

This one has to be fixed IMHO. I'm not sure how but we have to take a
decision. The current behaviour is really dangerous for most of our
users.

Perhaps so, but again, it's not a new regression, so why should it be
considered a blocker for 8.4beta?

Most of these are great patches. I would love to see them committed.
But at some point you have to draw a line in the sand. A decision was
taken that the last commitfest for 8.4 began 11/1/08. We have finally
managed to END that commitfest. I don't wish to have another,
unofficial one before beta. I want to go to beta as soon as humanly
possible and try to get this release out the door sometime in 2009.

...Robert

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Mar 26, 2009 at 10:11 PM, Bruce Momjian <bruce@momjian.us> wrote:

I think pushing "pre-existing bugs" to 8.5 is a mistake,

What is the threshold for "has to be fixed before we can go to beta"
versus "has to be fixed before release"?

I did not by any means intend that those things should wait until 8.5.
The point was that we needn't be ashamed to release an 8.4 *beta*
that has such bugs. Or at least no more than we are ashamed to have
released existing stable versions with 'em.

Beta is about getting a reasonably stable version into the hands of
testers. It's not about achieving perfection before the testers
ever see it.

regards, tom lane

On Fri, Mar 27, 2009 at 4:24 AM, Robert Haas <robertmhaas@gmail.com> wrote:

Perhaps so, but again, it's not a new regression, so why should it be
considered a blocker for 8.4beta?

I agree they shouldn't. You were talking about bumping them to 8.5
which is a totally different thing.

--
Guillaume

Guillaume Smet wrote:

On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas <robertmhaas@gmail.com> wrote:

That includes a whole slough of patches that weren't submitted until
after November 1st and which I think should probably be bumped en
masse to 8.5:

postgresql.conf: patch to have ParseConfigFile report all parsing
errors, then bail

Not sure about this one. A similar patch for the pg_hba.conf file
submitted after the commit fest (IIRC) has already been commited.

That can be argued to just be completing the pg_hba rewrite stuff that
happened long before november with the final logical step.

I guess if you stretch that definition as well, this could also be an
extension to that :)

//Magnus

On Fri, Mar 27, 2009 at 9:38 AM, Magnus Hagander <magnus@hagander.net> wrote:

That can be argued to just be completing the pg_hba rewrite stuff that
happened long before november with the final logical step.

I guess if you stretch that definition as well, this could also be an
extension to that :)

Yes, that was my point. I think it's better to be consistent for all
the configuration files.

On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas <robertmhaas@gmail.com> wrote:

I think we should also boot everything in the "pre-existing bugs"
category, and the first two items from the "questions" category, which
don't seem important enough to worry about at this stage of the game.
That would leave us with 14 items, all of which look reasonably
relevant and 8.4-related.

Comments?

FWIW, I posted my comments in the wiki. I tried to post useful
information about the status of each item I have an opinion about.

--
Guillaume

Robert Haas <robertmhaas@gmail.com> writes:

http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items

That includes a whole slough of patches that weren't submitted until
after November 1st and which I think should probably be bumped en
masse to 8.5:

Change behavior of statement-level triggers for inheritance cases?

Agreed: no patch submitted, not a bug (we'd never consider back-patching
such a change), and no obvious reason why it should be part of 8.4
rather than waiting.

GetCurrentVirtualXIDs() (is this patch safe?)

This is actually an extract from the hot standby patch, so I think it's
unfair to claim it was submitted too late. If I thought it were safe
I'd apply it, but I'm not convinced.

PQinitSSL broken in some use cases

This is a hard case. It's arguably a bug fix, but not one that we could
back-patch. I think we would have applied it by now if there were
consensus on which solution to pick.

postgresql.conf: patch to have ParseConfigFile report all parsing
errors, then bail

Agreed, this is in the "too late" category.

small but useful patches for text search

Ditto.

Additional DTrace Probes

This arguably is part of the existing 8.4 dtrace-related changes,
but it hasn't gotten any review that I saw. (And after having found
a number of problems in the earlier dtrace patches, I'm disinclined
to let it in without close review ...)

pg_standby trigger behavior is dangerous

Another sort-of-a-bug case; I'm inclined to leave it on the list
until a bit of consensus emerges.

psql \d commands and information_schema (already in CommitFest 2009-First)

This isn't a feature, it's a bug fix for the already committed changes
in \d's system-vs-user filtering. (Which I remain terribly unhappy with
in general, but that's a different list entry...)

Have \d show child tables that inherit from the specified parent
(already in CommitFest 2009-First)

Agreed, this is a new feature that can wait.

I think we should also boot everything in the "pre-existing bugs"
category,

Well, some of the things on this page are beta blockers and some are
just stuff that we'd like to address before final. Of the "pre existing
bugs", the only one that I'm really concerned about addressing before
beta is the polymorphic types vs. domains issue. Changing that has some
potential for breaking user apps so it'd be polite to make it happen
before beta starts. The rest should stay on the page, though, to be
addressed during beta.

and the first two items from the "questions" category, which
don't seem important enough to worry about at this stage of the game.

Both of those things are related to 8.4 feature changes, so we should
either do them now or decide we won't do them.

regards, tom lane

On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

PQinitSSL broken in some use cases

This is a hard case.  It's arguably a bug fix, but not one that we could
back-patch.  I think we would have applied it by now if there were
consensus on which solution to pick.

I think the consensus we were headed towards was wrong, or at least
not completely hashed out. IMO, the correct solution to this class of
problem is a generic library initialization routine (PQinit) that can
handle things of this nature without breaking the ABI down the line.
This solution felt controversial, and I definitely don't want to hold
up 8.4 trying to get it right.

So, my vote is to document the issue for 8.4, and hopefully come up
with something better for 8.5.

merlin

All,

On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas<robertmhaas@gmail.com> wrote:

I think we should also boot everything in the "pre-existing bugs"
category,

I don't agree. I think we should fix as many of those as we can without
holding up the release. Having been (briefly) in charge of Another Open
Source Database's bug list, I've seen where ignoring pre-existing bugs
can lead, and it's not at all pretty.

These bugs strike me as especially pernicious and to need fixing before
8.4 release (but NOT before Beta):

* GiST picksplit (maybe GIN too?) can fail
* Perl/libxml incompatibility
* BUG #4721: bad side-effects of limiting number of clauses that
predtest will consider
* BUG #4694: uppercase path problem on Windows

This one is also really bad, but probably only Doc-patchable. However,
can SQL/XML really be said to be core functionality if it only works in
UTF-8?
* BUG #4622: xpath only work in utf-8 server encoding

I'll also take a stab at this one, because it looks easy:
* contrib/intarray opclass definition needs updating

And Magnus fixed this one:
* Path separator consistency on Windows

The other "existing" bugs I think relate to extreme corner cases (e.g.
ENUMs of DOMAINS) and/or may be feature requests rather than bugs (e.g.
Cover Density Ranking) so I think can safely be put off until 8.4.1 or
later.

--Josh Berkus

On Fri, Mar 27, 2009 at 1:46 PM, Josh Berkus <josh@agliodbs.com> wrote:

All,

On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas<robertmhaas@gmail.com>
 wrote:

I think we should also boot everything in the "pre-existing bugs"
category,

I don't agree.  I think we should fix as many of those as we can without
holding up the release.  Having been (briefly) in charge of Another Open
Source Database's bug list, I've seen where ignoring pre-existing bugs can
lead, and it's not at all pretty.

I wish to recant my previous statement. I don't want to boot them - I
just don't want to hold up beta for them.

...Robert

Josh Berkus <josh@agliodbs.com> writes:

And Magnus fixed this one:
* Path separator consistency on Windows

Uh, no, that's still an open issue. Magnus put up a proposed patch that
I didn't like. I think it's arguable that we should be going the other
way: convert backslashes to slashes. Magnus's patch is the first step
towards trying to make the Windows port uniformly work with backslashes,
which is going to be an enormous mess and not worth the trouble IMHO.

regards, tom lane

It seems that we have full consensus about the following Open Items
not being material for 8.4, so I'm going to move them to the TODO
list or Commitfest 2009-First as appropriate:

* Change behavior of statement-level triggers for inheritance cases?

No patch, no interest in making it happen for 8.4 -> TODO

* PQinitSSL broken in some use cases

Arguably a bug, but Merlin was one of the instigators; since he's not
happy with where we are, it should be postponed.

* postgresql.conf: patch to have ParseConfigFile report all parsing errors, then bail

Not ready, and submitted very long past feature freeze -> commitfest

* small but useful patches for text search

Also submitted too late -> commitfest

* Have \d show child tables that inherit from the specified parent

Ditto. (The other \d issues relate to already-made 8.4 changes,
though, so they still need consideration; or else an explicit
decision that the current behavior is OK.)

regards, tom lane

Robert Haas wrote:

Wow, that is a large list. ?Getting this all on a wiki is really what
needed to happen. ?I can't keep an open list current enough to be
useful.

Ah, glad you like. I thought you'd been arguing the other side of
that point with me for several days, but no matter - it seems like we
might be converging on some kind of consensus here.

I prefer to do as little as possible.

I think we should also boot everything in the "pre-existing bugs"
category, and the first two items from the "questions" category, which
don't seem important enough to worry about at this stage of the game.
That would leave us with 14 items, all of which look reasonably
relevant and 8.4-related.

I think pushing "pre-existing bugs" to 8.5 is a mistake, first from a
software quality standpoint, and second because we are going to have a
lots of downtime during beta while we wait for feedback, so we can work
on some of these issues then. ?These things are not going to be any
easier to fix during 8.5 than now so let's make 8.4 as good as we can
without overly-delaying it.

What is the threshold for "has to be fixed before we can go to beta"
versus "has to be fixed before release"? I'm not opposed to fixing
the bugs, but it seems like every day that we postpone cutting a beta
is one more day until release, and so I think our immediate goal
should be to fix all of the things that need to be fixed before beta
can start.

Well, we don't want to be changing user-visible behavior during beta,
but anything we would fix in a minor release can be fixed during beta
too.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Fri, 27 Mar 2009, Josh Berkus wrote:

These bugs strike me as especially pernicious and to need fixing before 8.4
release (but NOT before Beta):

* GiST picksplit (maybe GIN too?) can fail

we have patch for recent problem raised by Sergey Konoplev (thanks Andrew for
the test case), which we're testing currently.

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

and the first two items from the "questions" category, which
don't seem important enough to worry about at this stage of the game.

Both of those things are related to 8.4 feature changes, so we should
either do them now or decide we won't do them.

Well, "Should we have a LOCALE option in CREATE DATABASE?" has to do
with making:

CREATE DATABASE foo WITH LOCALE = bar
equivalent to...
CREATE DATABASE foo WITH COLLATE = bar, CTYPE = bar

That might be nice to have, but since it's just syntactic sugar, I
disagree that it's now or never.

The second item, "Should we reject toast.fillfactor in reloptions?",
comes with a patch. I think I agree with ITAGAKI Takahiro that it
would be better to have reloptions specify a set of RELOPT_KINDs to
which they pertain rather than a single one. There are likely to be
other types of reloptions that could apply to more than one category
of objects, and duplicating the definitions is not a desirable coping
strategy. So I guess I'm in favor of applying this patch if others
are satisfied with the quality of the code (which I have looked at,
but only briefly). Given the fact that anyone who understands both
toast and fillfactor should know that they don't make sense together
(and we can also document this), I don't think too many people will
get bitten if we ignored this issue for 8.4 and then applied the patch
to 8.5, but since the code is already written, there may be no reason
to take the risk.

...Robert

Robert Haas <robertmhaas@gmail.com> writes:

On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Both of those things are related to 8.4 feature changes, so we should
either do them now or decide we won't do them.

Well, "Should we have a LOCALE option in CREATE DATABASE?" has to do
with making:

CREATE DATABASE foo WITH LOCALE = bar
equivalent to...
CREATE DATABASE foo WITH COLLATE = bar, CTYPE = bar

That might be nice to have, but since it's just syntactic sugar, I
disagree that it's now or never.

The reason I wanted it considered now is that part of the discussion
was about whether to rename the existing options (add or remove LC_,
I forget which). Once 8.4 is out it'll be too late to reconsider that.

The second item, "Should we reject toast.fillfactor in reloptions?",
comes with a patch. I think I agree with ITAGAKI Takahiro that it
would be better to have reloptions specify a set of RELOPT_KINDs to
which they pertain rather than a single one.

+1. And this is something it'd be better to get right now than later,
since it's about an API that's meant to be used by add-on modules.

regards, tom lane