Thread: Open 6.3.1 issues
We have several open issues with 6.3.1, which will probably have to be
addressed with a mega-patch, separate patches, or a minor release.
They are:
indexes not used that were used in 6.2
memory leak in backend when run on simple queries
negative sign causing problems in various areas, like float4 & shortint
configure assert checking is reversed
UNION crashes on ORDER BY or DISTINCT(already fixed in source tree)
We also have HAVING in the source tree.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
> We have several open issues with 6.3.1, which will probably have to be
> addressed with a mega-patch, separate patches, or a minor release.
I'm wondering what is causing the reported failures in the numerology
regression test, with Postgres having difficulty comparing a float8 to
an int4. It used to work, and it may have been tweaked just slightly so
that is a bit broken. Perhaps if we identify that we will find that
other things (like the "negative sign" problem, which afaik has been
this way forever) will fix themselves, at least for now.
- Tom
> Perhaps if we identify that we will find that
> other things (like the "negative sign" problem, which afaik has been
> this way forever) will fix themselves, at least for now.
I did make a small change to scan.l to fix problems with negative
numeric arguments to the CREATE SEQUENCE command. Does someone want to
try the scan.l and/or scan.c from v6.3 and see if it fixes anything?
_Might_ have an effect on the conversion from int4 to an int2 column as
reported recently.
- Tom
Bruce Momjian wrote: > > We have several open issues with 6.3.1, which will probably have to be > addressed with a mega-patch, separate patches, or a minor release. > > They are: > > indexes not used that were used in 6.2 Just fixed and CVSed. Introduced 1997/12/21: Remove some recursion in optimizer and clean up some code there. Bruce, could you check other changed places (I fixed just prune.c) ? Vadim
> > Bruce Momjian wrote: > > > > We have several open issues with 6.3.1, which will probably have to be > > addressed with a mega-patch, separate patches, or a minor release. > > > > They are: > > > > indexes not used that were used in 6.2 > > Just fixed and CVSed. > Introduced 1997/12/21: > Remove some recursion in optimizer and clean up some code there. > > Bruce, could you check other changed places (I fixed just prune.c) ? > > Vadim > Sure. That was really the only one where I really had trouble. The others were very clean changes. I had already fixed one bug in my new code in that place before the 6.3 release. The old code had an double-exponential growth search path that was unnessary. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
OK, we have most of the open items fixed. Marc, can you check on number 4, and Thomas, please apply your patch for item 3. We can then package a patch and close 6.3.*. > indexes not used that were used in 6.2(fixed) > memory leak in backend when run on simple queries(fixed) > negative sign causing problems in various areas, like float4 & shortint > configure assert checking is reversed > UNION crashes on ORDER BY or DISTINCT(already fixed in source tree) -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> OK, we have most of the open items fixed. Marc, can you check on number
> 4, and Thomas, please apply your patch for item 3. We can then package
> a patch and close 6.3.*.
>
> > indexes not used that were used in 6.2(fixed)
> > memory leak in backend when run on simple queries(fixed)
> > negative sign causing problems in various areas, like float4 & shortint
> > configure assert checking is reversed
> > UNION crashes on ORDER BY or DISTINCT(already fixed in source tree)
How do we want to package the patches? Shall we assemble the relevant
patches as we did p1-p7 for v6.2.1? There were reports of problems or
difficulties from some people regarding the 6.3->6.3.1 patch, which is
probably pretty complex. Also, there are some changes in the source
tree, like the char2-16 removal, which should not appear until v6.4.
So, I'd recommend that we take the individual patches fixing each
problem, apply them to a clean v6.3.1, run regression tests (since those
apparently broke in v6.3.1) and then release that set of patches at one
time.
I'd be willing to do the regression testing and then pass the patches
back for posting. Comments?
- Tom
> > > OK, we have most of the open items fixed. Marc, can you check on number > > 4, and Thomas, please apply your patch for item 3. We can then package > > a patch and close 6.3.*. > > > > > indexes not used that were used in 6.2(fixed) > > > memory leak in backend when run on simple queries(fixed) > > > negative sign causing problems in various areas, like float4 & shortint > > > configure assert checking is reversed > > > UNION crashes on ORDER BY or DISTINCT(already fixed in source tree) > > How do we want to package the patches? Shall we assemble the relevant > patches as we did p1-p7 for v6.2.1? There were reports of problems or > difficulties from some people regarding the 6.3->6.3.1 patch, which is > probably pretty complex. Also, there are some changes in the source > tree, like the char2-16 removal, which should not appear until v6.4. > > So, I'd recommend that we take the individual patches fixing each > problem, apply them to a clean v6.3.1, run regression tests (since those > apparently broke in v6.3.1) and then release that set of patches at one > time. I would think we are safer by releasing a new diff. The char2-16 changes are the only ones I know of that should not have been applied (by me!), so we can back them out. Just seems it is too easy to miss some part of the patch. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
Bruce Momjian <maillist@candle.pha.pa.us> writes: > I would think we are safer by releasing a new diff. ...as in: a new minor version, right? There's no good reason not to bump it to 6.3.2, and if you do that, it becomes easier for people who report problems and what not to specify exactly what they're running. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
> > > > indexes not used that were used in 6.2(fixed)
> > > > memory leak in backend when run on simple queries(fixed)
> > > > negative sign causing problems in various areas
> > > > configure assert checking is reversed
> > > > UNION crashes on ORDER BY or DISTINCT
> I would think we are safer by releasing a new diff. The char2-16
> changes are the only ones I know of that should not have been applied
> (by me!), so we can back them out. Just seems it is too easy to miss
> some part of the patch.
Well, we have the other side of the problem to worry about too: that
with changes in the source tree, there may be unanticipated interactions
with other patches when we are really trying to fix only 5 specific
problems.
I would like to do a test with specific patches on a clean v6.3.1
installation, and then we can compare the patches from my test with
patches from the CVS extraction. I'll isolate my "negative sign" fixes
(which I haven't yet committed to the source tree, but which I think
just need a reversion of scan.l/scan.c to the v6.3 release).
Can you (re)send me the patches for these others? I still have the
"memory leak" patches, but can't remember who posted the "index" and
"UNION" patches (were they all yours Bruce?? Probably gone from my mail
anyway).
- Tom
> > > > > > indexes not used that were used in 6.2(fixed) > > > > > memory leak in backend when run on simple queries(fixed) > > > > > negative sign causing problems in various areas > > > > > configure assert checking is reversed > > > > > UNION crashes on ORDER BY or DISTINCT > > I would think we are safer by releasing a new diff. The char2-16 > > changes are the only ones I know of that should not have been applied > > (by me!), so we can back them out. Just seems it is too easy to miss > > some part of the patch. > > Well, we have the other side of the problem to worry about too: that > with changes in the source tree, there may be unanticipated interactions > with other patches when we are really trying to fix only 5 specific > problems. > > I would like to do a test with specific patches on a clean v6.3.1 > installation, and then we can compare the patches from my test with > patches from the CVS extraction. I'll isolate my "negative sign" fixes > (which I haven't yet committed to the source tree, but which I think > just need a reversion of scan.l/scan.c to the v6.3 release). > > Can you (re)send me the patches for these others? I still have the > "memory leak" patches, but can't remember who posted the "index" and > "UNION" patches (were they all yours Bruce?? Probably gone from my mail > anyway). Vadim did the index one, and I think I have a copy. The UNION was several patches by the time I was happy with it, so I would have to do a diff on just the files I know I changed. None of the current bugs are from changes made between 6.3 and 6.3.1 except the negative patch, so I can't see us adding more problems. The regression test did not show these problems either, so I have little confidence that they will find new bugs we may be introducing. If we go with the current tree, we can have people who use cvsup keep testing the snapshot until we are happy with it. We will probably need Marc to make this decision. It can be argued either way. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> > Bruce Momjian <maillist@candle.pha.pa.us> writes: > > > I would think we are safer by releasing a new diff. > > ...as in: a new minor version, right? There's no good reason not to > bump it to 6.3.2, and if you do that, it becomes easier for people who > report problems and what not to specify exactly what they're running. Exactly. We also have more fixes. By the time you package up all the diffs and test them, might was well take a new snapshot of the current source. Also, it allows people to test the current tree and make changes until the final patch release. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> > > OK, we have most of the open items fixed. Marc, can you check on number > > 4, and Thomas, please apply your patch for item 3. We can then package > > a patch and close 6.3.*. > > > > > indexes not used that were used in 6.2(fixed) > > > memory leak in backend when run on simple queries(fixed) > > > negative sign causing problems in various areas, like float4 & shortint > > > configure assert checking is reversed > > > UNION crashes on ORDER BY or DISTINCT(already fixed in source tree) > > How do we want to package the patches? Shall we assemble the relevant > patches as we did p1-p7 for v6.2.1? There were reports of problems or > difficulties from some people regarding the 6.3->6.3.1 patch, which is I believe these problems were because Marc's copy of one of the geqo files was zero length. Once he fixed that, I don't remember any other problems. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
On Sun, 5 Apr 1998, Bruce Momjian wrote:
> >
> > > > > > indexes not used that were used in 6.2(fixed)
> > > > > > memory leak in backend when run on simple queries(fixed)
> > > > > > negative sign causing problems in various areas
> > > > > > configure assert checking is reversed
> > > > > > UNION crashes on ORDER BY or DISTINCT
> > > I would think we are safer by releasing a new diff. The char2-16
> > > changes are the only ones I know of that should not have been applied
> > > (by me!), so we can back them out. Just seems it is too easy to miss
> > > some part of the patch.
> >
> > Well, we have the other side of the problem to worry about too: that
> > with changes in the source tree, there may be unanticipated interactions
> > with other patches when we are really trying to fix only 5 specific
> > problems.
> >
> > I would like to do a test with specific patches on a clean v6.3.1
> > installation, and then we can compare the patches from my test with
> > patches from the CVS extraction. I'll isolate my "negative sign" fixes
> > (which I haven't yet committed to the source tree, but which I think
> > just need a reversion of scan.l/scan.c to the v6.3 release).
> >
> > Can you (re)send me the patches for these others? I still have the
> > "memory leak" patches, but can't remember who posted the "index" and
> > "UNION" patches (were they all yours Bruce?? Probably gone from my mail
> > anyway).
>
> Vadim did the index one, and I think I have a copy. The UNION was
> several patches by the time I was happy with it, so I would have to do a
> diff on just the files I know I changed.
>
> None of the current bugs are from changes made between 6.3 and 6.3.1
> except the negative patch, so I can't see us adding more problems.
>
> The regression test did not show these problems either, so I have little
> confidence that they will find new bugs we may be introducing. If we go
> with the current tree, we can have people who use cvsup keep testing the
> snapshot until we are happy with it.
>
> We will probably need Marc to make this decision. It can be argued
> either way.
I just read through all the posts on this subject (it was one busy
weekend), and considering that we *just* put out v6.3.1, I don't really
like the idea of doing another v6.3.2...
for v6.2.1, when Vadim has a problem that he fixed against that,
he put out a quick patch for that individual bug...
IMHO, v6.3.1 was a post-release release, mainly to work on and fix
bugs based on what those who were afraid of using the beta software
reported...anything else from that point should just be issued as
individual patches to address individual problems...
The patches listed above are great, and serve an important
function, but by fixing those, what other problem(s) have been introduced?
Has there been ample testing of the newest 'current' to release it as a
*release*, that alot of ppl will download and use?
Put them up as "official patches" against v6.3.1, but no
v6.3.2...not so close behind v6.3.1 :(
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes: > Put them up as "official patches" against v6.3.1, but no > v6.3.2...not so close behind v6.3.1 :( Whatever you choose to do, make sure it's well reasoned out and that you will then continue to follow that scheme! You have to decide what will be "releases" and what will be "interim". For instance, you could say that 6.3 is a release, and 6.4 will be one, while 6.3.N (for a possibly large number of sequentially allocated values for N) will be interim releases. On the other hand, you could call 6.3.1 a release, and then go for 6.3.1.N, after the same scheme. (This seems to be what Marc wants.) Next it is necessary to decide whether the interim releases will be snapshots of the development tree or a separate branch where important problems are fixed by patches that are derived from the main branch. The former is easier on the developers, the latter option means that two versions of the code tree must be administered (if they're both in the same actual CVS tree, they will be different branches). In any case, make sure that upgrading is a step by step operation, yielding a numerically increasing sequence of version numbers (or version number plus patchlevel, if you like), so that it will always be possible to say "I run version so-and-so", and _not_ "well, I run version so-and-so, and I've applied the patches for this and that, and that other patch that I also needed". While I'm writing: are these lists gatewayed to USENET somehow? It seems to me that my posting to PostgreSQL lists causes an increase in the amount of garbage I receive from the sort of people whom I'd like to have some time alone with -- with a baseball bat, while they were tied up. Yup, people who send unsolicited commercial email. If there is such a gateway, I'd like to know, so I can stop sending anything to these lists. (I've stopped using USENET altogether for this reason.) -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
> The Hermit Hacker <scrappy@hub.org> writes: > > > Put them up as "official patches" against v6.3.1, but no > > v6.3.2...not so close behind v6.3.1 :( > > Whatever you choose to do, make sure it's well reasoned out and that > you will then continue to follow that scheme! > Agreed, most of your arguments have been gone over a while ago. But I disagree VERY strongly with Marc, a new set of patches should DEFINITELY be 6.3.2. What does it matter that this is so close behind 6.3.1 - that simply shows that the PostgreSQL developers have responded to and fixed a number of bugs in double-quick time. OK, so it's a little embarrassing that these weren't spotted before 6.3 was released, but it makes things so much simpler for everyone to say "I'm running 6.3.2" rather than "I'm running 6.3.1 patched with patch xyz (which I may or may not have applied correctly...)" If Marc can come up with one really solid reason why a patched version should NOT be released as 6.3.2, I might reconsider my viewpoint :-) Andrew ---------------------------------------------------------------------------- Dr. Andrew C.R. Martin University College London EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk URL: http://www.biochem.ucl.ac.uk/~martin Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775