RE: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, Mikheev, Vadim wrote: Um, you do realize that a contrib module that gets used as part of the regress tests may as well be mainstream? At least in terms of the portability requirements it will have to meet? I'm unhappy again. Bad enough we accepted a new feature during beta; now we're going to expect an absolutely virgin contrib module to work everywhere in order to pass regress tests? Ops, agreed. And I fear that in current code there is no one GiST index implementation -:( Should we worry about regress tests? -:) Yes, we had to write contrib module even to test GiST. People, I'm really confused after reading all of messages. GiST is just an interface and to test any interface you need 2 sides. In current code there is only one side. old GiST code live untested for years. What's the problem ? It's the problem of current regression test, mostly. Ok. We could rewrite R-Tree to use GiST and make regression test which will not make people nervous. But this certainly not for 7.1 and most probable without us. Author of R-Tree could write this easily. I read Bruce's interview and was really relaxed - how everything is going well. Bruce, we need your opinion. Oleg Vadim Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
RE: AW: [HACKERS] Re: GiST for 7.1 !!
OK. We found an old implementation of R-Tre using GiST (Pg95) and we'll try to implement regression test using R-Tree it's anyway will be a good test. Regards, Oleg On Fri, 12 Jan 2001, Oleg Bartunov wrote: On Thu, 11 Jan 2001, Mikheev, Vadim wrote: Um, you do realize that a contrib module that gets used as part of the regress tests may as well be mainstream? At least in terms of the portability requirements it will have to meet? I'm unhappy again. Bad enough we accepted a new feature during beta; now we're going to expect an absolutely virgin contrib module to work everywhere in order to pass regress tests? Ops, agreed. And I fear that in current code there is no one GiST index implementation -:( Should we worry about regress tests? -:) Yes, we had to write contrib module even to test GiST. People, I'm really confused after reading all of messages. GiST is just an interface and to test any interface you need 2 sides. In current code there is only one side. old GiST code live untested for years. What's the problem ? It's the problem of current regression test, mostly. Ok. We could rewrite R-Tree to use GiST and make regression test which will not make people nervous. But this certainly not for 7.1 and most probable without us. Author of R-Tree could write this easily. I read Bruce's interview and was really relaxed - how everything is going well. Bruce, we need your opinion. Oleg Vadim Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Tom Lane wrote: Um, you do realize that a contrib module that gets used as part of the regress tests may as well be mainstream? At least in terms of the portability requirements it will have to meet? _If_ we want to have a tested GiST (and not the "probably works but really has some nasty known bugs" one) we need to write _tests_. To test it we need something that makes use of it. As the only things that make use of it are extensions we need to make use of them in tests. So I propose the following : 1. Keep the fixed (new) gist.c in the main codebase 2. make use of the RD-index and/or Gene's tests in contrib in regression tests 3. Tellpeople beforehand that it is not the end of the world if GiST _tests_ fail on their platform I'm unhappy again. Bad enough we accepted a new feature during beta; now we're going to expect an absolutely virgin contrib module to work everywhere in order to pass regress tests? There can be always "expected" discrepancies in regress tests, and failing GiST test just tells people that if they want to use GiST on their platform they must probably fix things in core code as well. Currently they have to find it out the hard way - first lot of work trying to "fix" their own code and only then the bright idea that maybe it is actually broken in the core. IMHO, giving out real test results, even negative, instead of leaving things untested would be a honest thing to do. - Hannu
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Fri, 12 Jan 2001, Hannu Krosing wrote: Oleg Bartunov wrote: OK. We found an old implementation of R-Tre using GiST (Pg95) and we'll try to implement regression test using R-Tree it's anyway will be a good test. How is it different than using RD-tree for tests ? No difference at all ! It's just another implemetation of R-Tree. Can you do it usin already compiled-in functions and modifying things only at SQL level ? unfortunately not ! Current postgres code has nothing connected with GiST and this is a problem ! How to test interface code without having two sides ? I understand we don't want to have another reason for complaints about non-working regression test. I never got regression test passed 100% on my Linux box with almost all versions of PostgreSQL but I could live with that. What's wrong with warning message if GiST test not passed ? Or is it just much simpler ? I'm interesting to test performance of built-in R-Tree and R-Tree + GiST. Oleg - Hannu Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Oleg Bartunov [EMAIL PROTECTED] writes: What's wrong with warning message if GiST test not passed ? You're being *way* too optimistic. An output discrepancy in a test of GIST we could live with. But think about other scenarios: 1. GIST test coredumps on some platforms. This corrupts other tests (at least through the "system is starting up" failure mode), thus masking problems that we actually care about. 2. GIST test code does not compile on some platforms, causing "make check" to fail completely. At this point my vote is to leave the GIST test in contrib for 7.1. Anyone who actually cares about GIST (to be blunt: all three of you) can run it as a separate step. I don't want it in the standard regress tests until 7.2, when we will have a reasonable amount of time to test and debug the test. regards, tom lane
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Fri, 12 Jan 2001, Oleg Bartunov wrote: On Fri, 12 Jan 2001, Hannu Krosing wrote: Oleg Bartunov wrote: OK. We found an old implementation of R-Tre using GiST (Pg95) and we'll try to implement regression test using R-Tree it's anyway will be a good test. How is it different than using RD-tree for tests ? No difference at all ! It's just another implemetation of R-Tree. Can you do it usin already compiled-in functions and modifying things only at SQL level ? unfortunately not ! Current postgres code has nothing connected with GiST and this is a problem ! How to test interface code without having two sides ? I understand we don't want to have another reason for complaints about non-working regression test. I never got regression test passed 100% on my Linux box with almost all versions of PostgreSQL but I could live with that. What's wrong with warning message if GiST test not passed ? It has *nothing* to do with passing or not, it has to do with timing of hte patches ... had they come in before we went beta, this would all have been a no-brainer ... because they didn't, the problem arises ... GiST changes are included ... testing of GiST changes aren't integrated ... can we *please* drop this whole thing already, as its really detracting from getting *real* work done with very little, to no, benefit ...
Beta4 for GiST? (Was: Re: AW: [HACKERS] Re: GiST for 7.1 !! )
On Fri, 12 Jan 2001, Tom Lane wrote: Oleg Bartunov [EMAIL PROTECTED] writes: What's wrong with warning message if GiST test not passed ? You're being *way* too optimistic. An output discrepancy in a test of GIST we could live with. But think about other scenarios: 1. GIST test coredumps on some platforms. This corrupts other tests (at least through the "system is starting up" failure mode), thus masking problems that we actually care about. 2. GIST test code does not compile on some platforms, causing "make check" to fail completely. At this point my vote is to leave the GIST test in contrib for 7.1. Anyone who actually cares about GIST (to be blunt: all three of you) can run it as a separate step. I don't want it in the standard regress tests until 7.2, when we will have a reasonable amount of time to test and debug the test. Agreed ... now let's move onto more important things, cause we've spent much too long on this as it is ... Namely, should we bundle up a beta4 this weeekend, so that the GiST changes are in place for further testing, or hold off for ... ?
Re: AW: [HACKERS] Re: GiST for 7.1 !!
At this point my vote is to leave the GIST test in contrib for 7.1. Anyone who actually cares about GIST (to be blunt: all three of you) can run it as a separate step. I don't want it in the standard regress tests until 7.2, when we will have a reasonable amount of time to test and debug the test. Agreed. I want the GIST fixes in 7.1, but adding a new test at this point is too risky. The issue is that only the GIST people will be using the GIST fixes, while adding it to the regression test will affect all users, which is too risky at this point. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: Beta4 for GiST? (Was: Re: AW: [HACKERS] Re: GiST for 7.1 !! )
Agreed ... now let's move onto more important things, cause we've spent much too long on this as it is ... Namely, should we bundle up a beta4 this weeekend, so that the GiST changes are in place for further testing, or hold off for ... ? I would hold off. GIST people can download the snapshot. Others aren't interested in GIST. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: Beta4 for GiST? (Was: Re: AW: [HACKERS] Re: GiST for 7.1 !! )
On Fri, 12 Jan 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Namely, should we bundle up a beta4 this weeekend, so that the GiST changes are in place for further testing, or hold off for ... ? First I'd like to finish a couple of open items I have, like fixing the CRIT_SECTION code so that SIGTERM response will not occur when we are holding a spinlock. Should be able to get this stuff done in a day or two, if I quit arguing about GIST and get back to work... Okay, let's scheduale for Monday then if we can ... unless someone comes across something major like we did with the whole beta2/beta3 release :)
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, Zeugswetter Andreas SB wrote: we've almost totally rewrite gist.c because old code and algorithm were not suitable for variable size keys. I think it might be submitted into 7.1 beta source tree. Urgh. Dropping in a total rewrite when we're already past beta3 doesn't strike me as good project management practice --- especially if the rewrite was done to add features (ie variable-size keys) not merely fix bugs. I think it might be more prudent to hold this for 7.2. OK. If our changes will not go to 7.1, is't possible to create feature archive and announce it somewhere. It would be nice if people could test it. Anyway, I'll create web page with all docs and patches. I'm afraid one more year to 7.2 is enough for GiST to die :-) I think featureism is the the most prominent argument for PostgreSQL. Thus standing before a decision to eighter fix GiST bugs and risc a new bug (limited to GiST) because of an added feature or shipping a known broken GiST, my vote would definitely be to add Oleg's patch. Definetely, our changes limited to GiST insert algorithm only. Other changes are bugfixes. I encourage people interested in GiST to test my submission. Our implementation of RD-Tree which we used to support of indexing of int4 arrays will works only with our version of gist.c (actually our interest to GiST was motivated by index support of int4 arrays). Regards, Oleg Andreas _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Hannu Krosing [EMAIL PROTECTED] writes: That's my vote too, specially if there will be some regression tests accompanying the patches. The current (pre-patch) state of affairs with GiST could probably be described as security-by-obscurity anyhow i.e. "we have't tried it so we think it probably works" ;-) Au contraire, there *are* a few users of GiST out there now, Gene Selkov to name one. So there is a definite risk of breaking things that worked in 7.0 and before, in the name of adding new features. If I thought that we had adequate ability to test the new GiST implementation during the remaining beta period, I wouldn't be so worried. But at this point, Oleg's changes could not appear in the beta series before beta4, and between the late date, the lack of regression test, and the few interested people to test it, I doubt that we'll get any useful coverage. I would recommend that Oleg do like Ryan K. did for awhile with the Alpha patches: make them available as a set of diffs to be applied to the official distribution. We'll be happy to merge them in for 7.2, but the calendar says it's too late for 7.1. regards, tom lane
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: That's my vote too, specially if there will be some regression tests accompanying the patches. The current (pre-patch) state of affairs with GiST could probably be described as security-by-obscurity anyhow i.e. "we have't tried it so we think it probably works" ;-) Au contraire, there *are* a few users of GiST out there now, Gene Selkov to name one. Yes, he is the only one (except Oleg) whom I know to use it too ;) So there is a definite risk of breaking things that worked in 7.0 and before, in the name of adding new features. True. Could we ask Gene to test 7.1 with Oleg's patches ? If I thought that we had adequate ability to test the new GiST implementation during the remaining beta period, I wouldn't be so worried. But at this point, Oleg's changes could not appear in the beta series before beta4, and between the late date, the lack of regression test, and the few interested people to test it, I doubt that we'll get any useful coverage. Or if in fact there _are_ only a few people using it now we could get _all_ the coverage to be sufficiently sure we don't break anyones code. GiST being such an obscure and underused feature I'm pretty sure that most (all?) active users are on Hackers list and read everything that has GiST in subject. I would recommend that Oleg do like Ryan K. did for awhile with the Alpha patches: make them available as a set of diffs to be applied to the official distribution. We'll be happy to merge them in for 7.2, but the calendar says it's too late for 7.1. Even for the _real_ bugfixes in gist.c ? Hannu
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Hannu Krosing [EMAIL PROTECTED] writes: ... the calendar says it's too late for 7.1. Even for the _real_ bugfixes in gist.c ? If he were submitting only bugfixes, we wouldn't be having this discussion. Look, I don't like postponing improvements either. But if we don't adhere to project management discipline, we are never going to get releases out the door at all --- or if we do, they'll be too buggy to be reliable. It's not like "no new features during beta" is such a draconian or difficult-to-understand rule. The RelFileNodeEquals() bug we found on Monday proves that no one had yet done enough stress-testing on 7.1 to discover that multiple databases were broken. Think about that for awhile before you campaign for inserting untested new features at this point. We need to focus on TESTING, people, not new features. regards, tom lane
RE: AW: [HACKERS] Re: GiST for 7.1 !!
The RelFileNodeEquals() bug we found on Monday proves that no one had yet done enough stress-testing on 7.1 to discover that multiple databases were broken. Think about that for awhile before you campaign for inserting untested new features at this point. We need to focus on TESTING, people, not new features. I mostly sure that Oleg' changes touch *only* gist subdir (Oleg?) so *nothing* will be broken in other areas. That's why I don't object new gist in 7.1. RelFileNodeEquals is quite another thing, thanks for fix again -:) Vadim
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: ... the calendar says it's too late for 7.1. Even for the _real_ bugfixes in gist.c ? If he were submitting only bugfixes, we wouldn't be having this discussion. But he had very little incentive to fix bugs in the version he would not use. Look, I don't like postponing improvements either. But if we don't adhere to project management discipline, But should we do that _blindly_? I'd think that improving/fixing things in seldom-visited corners of postgres should be a little more tolerable than messing around in core. we are never going to get releases out the door at all --- or if we do, they'll be too buggy to be reliable. It's not like "no new features during beta" is such a draconian or difficult-to-understand rule. I'd rather describe his changes as "a (bug)fix that required a major rewrite" ;) The RelFileNodeEquals() bug we found on Monday proves that no one had yet done enough stress-testing on 7.1 to discover that multiple databases were broken. BTW, What do people use for stress-testing ? Think about that for awhile before you campaign for inserting untested new features at this point. Rather new variants of little-tested features ;) We need to focus on TESTING, people, not new features. I make a personal promise to spend at least 5 hours of testing new GiST functionality during this weekend if it is commited to 7.1 CVS. (ok, I do it anyhow, just that currently I'm testing it using the patches ;) - Hannu
RE: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, Mikheev, Vadim wrote: The RelFileNodeEquals() bug we found on Monday proves that no one had yet done enough stress-testing on 7.1 to discover that multiple databases were broken. Think about that for awhile before you campaign for inserting untested new features at this point. We need to focus on TESTING, people, not new features. I mostly sure that Oleg' changes touch *only* gist subdir (Oleg?) Yes, and only one file - gist.c so *nothing* will be broken in other areas. That's why I don't object new gist in 7.1. We prepare regression test for RD-Tree in the same way as Gene does for his contribution. I put all files on http://www.sai.msu.su/~megera/postgres/gist/. btw, all Gene's test for seg and cube in contrib area are passed. It would be better Gene check his application himself. I'm sorry for trouble with my submission - I hoped we will be ready before beta2,3, but we spent too many time to get old insertion algoritm works with variable size keys until we realized it's just not suitable for this. I understand Tom's arguments and respect his experience, so I think it's possible to put link to my page in 7.1 docs for people interested in GiST features. Also, we found GiST part of postgres documentation is too short, so we'll try to contribute something sometime later. From other side, GiST was too hidden for people, while it's very powerfull feature and many people for sure really needs GiST power. Frankly speaking I discovered GiST power myself by accident :-) Now we have many plans to use GiST in our real life applications such as Web site management system, full text search (killer application !), data mining and others. There are several improvements and new features we plan to add to GiST which could be go to 7.2. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, Hannu Krosing wrote: I make a personal promise to spend at least 5 hours of testing new GiST functionality during this weekend if it is commited to 7.1 CVS. (ok, I do it anyhow, just that currently I'm testing it using the patches ;) Hanny, latest version is available at http://www.sai.msu.su/~megera/postgres/gist/ nothing changed in code (in compare with my submission), just added some info and regression test. Let me know if you need some help. Oleg - Hannu Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Oleg Bartunov [EMAIL PROTECTED] writes: I understand Tom's arguments and respect his experience, so I think it's possible to put link to my page in 7.1 docs for people interested in GiST features. Bear in mind that I only have one core vote ;-). We've already had some private core discussion about whether to accept this patch now, and so far I think I'm outvoted. Did I understand you to say that you'd added some regression tests for GiST? That would lessen my unhappiness a little bit ... regards, tom lane
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, Tom Lane wrote: Oleg Bartunov [EMAIL PROTECTED] writes: I understand Tom's arguments and respect his experience, so I think it's possible to put link to my page in 7.1 docs for people interested in GiST features. Bear in mind that I only have one core vote ;-). We've already had some private core discussion about whether to accept this patch now, and so far I think I'm outvoted. There are several Tom Lane, judge by your activity. You probably need several votes. Did I understand you to say that you'd added some regression tests for GiST? That would lessen my unhappiness a little bit ... Yes, we did. Currently all files are available from my page http://www.sai.msu.su/~megera/postgres/gist/ I could submit them to hackers list if CORE people got consensus Regards, Oleg regards, tom lane Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Fri, 12 Jan 2001, Oleg Bartunov wrote: On Thu, 11 Jan 2001, Tom Lane wrote: Oleg Bartunov [EMAIL PROTECTED] writes: I understand Tom's arguments and respect his experience, so I think it's possible to put link to my page in 7.1 docs for people interested in GiST features. Bear in mind that I only have one core vote ;-). We've already had some private core discussion about whether to accept this patch now, and so far I think I'm outvoted. There are several Tom Lane, judge by your activity. You probably need several votes. Did I understand you to say that you'd added some regression tests for GiST? That would lessen my unhappiness a little bit ... Yes, we did. Currently all files are available from my page http://www.sai.msu.su/~megera/postgres/gist/ I could submit them to hackers list if CORE people got consensus Okay, if there are appropriate regression tests, I'm going to say go for it ... Does anyone have any objections to my downloading the tar file (doing that now), committing the changes and wrapping up a quick Beta4 just so that we have a tar ball that is testable right away? Save Lamar and the other packagers a bit of work by avoiding beta3 packages :)
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, The Hermit Hacker wrote: just downloaded it and can't find any regression tests ... ? it's in the contrib-intarray.tar.gz gmake, gmake install, gmake installcheck Oleg On Thu, 11 Jan 2001, The Hermit Hacker wrote: On Fri, 12 Jan 2001, Oleg Bartunov wrote: On Thu, 11 Jan 2001, Tom Lane wrote: Oleg Bartunov [EMAIL PROTECTED] writes: I understand Tom's arguments and respect his experience, so I think it's possible to put link to my page in 7.1 docs for people interested in GiST features. Bear in mind that I only have one core vote ;-). We've already had some private core discussion about whether to accept this patch now, and so far I think I'm outvoted. There are several Tom Lane, judge by your activity. You probably need several votes. Did I understand you to say that you'd added some regression tests for GiST? That would lessen my unhappiness a little bit ... Yes, we did. Currently all files are available from my page http://www.sai.msu.su/~megera/postgres/gist/ I could submit them to hackers list if CORE people got consensus Okay, if there are appropriate regression tests, I'm going to say go for it ... Does anyone have any objections to my downloading the tar file (doing that now), committing the changes and wrapping up a quick Beta4 just so that we have a tar ball that is testable right away? Save Lamar and the other packagers a bit of work by avoiding beta3 packages :) Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Fri, 12 Jan 2001, Oleg Bartunov wrote: On Thu, 11 Jan 2001, The Hermit Hacker wrote: just downloaded it and can't find any regression tests ... ? it's in the contrib-intarray.tar.gz gmake, gmake install, gmake installcheck erk, can we get this somehow done in such a way that its part of the *standard* regression tests? so when ppl do 'make test', the GiST stuff is checked also? My worry, as with others, isn't that GiST itself is broken by the changes, its that *somehow* there is an interaction that is with the rest of the system that isn't being tested ... Oleg On Thu, 11 Jan 2001, The Hermit Hacker wrote: On Fri, 12 Jan 2001, Oleg Bartunov wrote: On Thu, 11 Jan 2001, Tom Lane wrote: Oleg Bartunov [EMAIL PROTECTED] writes: I understand Tom's arguments and respect his experience, so I think it's possible to put link to my page in 7.1 docs for people interested in GiST features. Bear in mind that I only have one core vote ;-). We've already had some private core discussion about whether to accept this patch now, and so far I think I'm outvoted. There are several Tom Lane, judge by your activity. You probably need several votes. Did I understand you to say that you'd added some regression tests for GiST? That would lessen my unhappiness a little bit ... Yes, we did. Currently all files are available from my page http://www.sai.msu.su/~megera/postgres/gist/ I could submit them to hackers list if CORE people got consensus Okay, if there are appropriate regression tests, I'm going to say go for it ... Does anyone have any objections to my downloading the tar file (doing that now), committing the changes and wrapping up a quick Beta4 just so that we have a tar ball that is testable right away? Save Lamar and the other packagers a bit of work by avoiding beta3 packages :) Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, The Hermit Hacker wrote: On Fri, 12 Jan 2001, Oleg Bartunov wrote: On Thu, 11 Jan 2001, The Hermit Hacker wrote: just downloaded it and can't find any regression tests ... ? it's in the contrib-intarray.tar.gz gmake, gmake install, gmake installcheck erk, can we get this somehow done in such a way that its part of the *standard* regression tests? so when ppl do 'make test', the GiST stuff is checked also? My worry, as with others, isn't that GiST itself is broken by the changes, its that *somehow* there is an interaction that is with the rest of the system that isn't being tested ... No way, we need to load functions. there are several contributions which depends on loaded functions. If you suggest how to do this in general way, it would fine. To test GiST you need to define some data structure ( in our case - RD-tree) and functions to access it Oleg On Thu, 11 Jan 2001, The Hermit Hacker wrote: On Fri, 12 Jan 2001, Oleg Bartunov wrote: On Thu, 11 Jan 2001, Tom Lane wrote: Oleg Bartunov [EMAIL PROTECTED] writes: I understand Tom's arguments and respect his experience, so I think it's possible to put link to my page in 7.1 docs for people interested in GiST features. Bear in mind that I only have one core vote ;-). We've already had some private core discussion about whether to accept this patch now, and so far I think I'm outvoted. There are several Tom Lane, judge by your activity. You probably need several votes. Did I understand you to say that you'd added some regression tests for GiST? That would lessen my unhappiness a little bit ... Yes, we did. Currently all files are available from my page http://www.sai.msu.su/~megera/postgres/gist/ I could submit them to hackers list if CORE people got consensus Okay, if there are appropriate regression tests, I'm going to say go for it ... Does anyone have any objections to my downloading the tar file (doing that now), committing the changes and wrapping up a quick Beta4 just so that we have a tar ball that is testable right away? Save Lamar and the other packagers a bit of work by avoiding beta3 packages :) Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
RE: AW: [HACKERS] Re: GiST for 7.1 !!
erk, can we get this somehow done in such a way that its part of the *standard* regression tests? so when ppl do 'make test', the GiST stuff is checked also? My worry, as with others, isn't that GiST itself is broken by the changes, its that *somehow* there is an interaction that is with the rest of the system that isn't being tested ... No way, we need to load functions. there are several contributions which depends on loaded functions. If you suggest how to do this in general way, it would fine. To test GiST you need to define some data structure ( in our case - RD-tree) and functions to access it Look at regress/input/create_function_1.source for hints from SPI tests... Vadim
RE: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, Mikheev, Vadim wrote: erk, can we get this somehow done in such a way that its part of the *standard* regression tests? so when ppl do 'make test', the GiST stuff is checked also? My worry, as with others, isn't that GiST itself is broken by the changes, its that *somehow* there is an interaction that is with the rest of the system that isn't being tested ... No way, we need to load functions. there are several contributions which depends on loaded functions. If you suggest how to do this in general way, it would fine. To test GiST you need to define some data structure ( in our case - RD-tree) and functions to access it Look at regress/input/create_function_1.source for hints from SPI tests... Thanks Vadim for tips. Will do this way, but tommorow. It's 3:19 am already and I have to sleep :-) Vadim Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Oleg Bartunov [EMAIL PROTECTED] writes: No way, we need to load functions. there are several contributions which depends on loaded functions. If you suggest how to do this in general way, it would fine. To test GiST you need to define some data structure ( in our case - RD-tree) and functions to access it Look at regress/input/create_function_1.source for hints from SPI tests... Um, you do realize that a contrib module that gets used as part of the regress tests may as well be mainstream? At least in terms of the portability requirements it will have to meet? I'm unhappy again. Bad enough we accepted a new feature during beta; now we're going to expect an absolutely virgin contrib module to work everywhere in order to pass regress tests? regards, tom lane
RE: AW: [HACKERS] Re: GiST for 7.1 !!
Um, you do realize that a contrib module that gets used as part of the regress tests may as well be mainstream? At least in terms of the portability requirements it will have to meet? I'm unhappy again. Bad enough we accepted a new feature during beta; now we're going to expect an absolutely virgin contrib module to work everywhere in order to pass regress tests? Ops, agreed. And I fear that in current code there is no one GiST index implementation -:( Should we worry about regress tests? -:) Vadim
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Tom Lane wrote: Um, you do realize that a contrib module that gets used as part of the regress tests may as well be mainstream? At least in terms of the portability requirements it will have to meet? I'm unhappy again. Bad enough we accepted a new feature during beta; now we're going to expect an absolutely virgin contrib module to work everywhere in order to pass regress tests? Last I checked, two contrib modules had to be built for regression testing. But that was 7.0. (autoinc and refint.). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I'm unhappy again. Bad enough we accepted a new feature during beta; now we're going to expect an absolutely virgin contrib module to work everywhere in order to pass regress tests? Last I checked, two contrib modules had to be built for regression testing. Sure, but they've been there awhile. All of my concerns here are schedule-driven: do we really want to be wringing out a new contrib module, to the point where it will run everywhere, before we can release 7.1? Are the benefits worth the effort? Can the current GiST developers pull it off in time? If the answer to either question is not a resounding YES then we really don't need to go down this road. Either leave it in contrib and regression testless (with a test script in the contrib), or make it a feature patch. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I'm unhappy again. Bad enough we accepted a new feature during beta; now we're going to expect an absolutely virgin contrib module to work everywhere in order to pass regress tests? Last I checked, two contrib modules had to be built for regression testing. Sure, but they've been there awhile. All of my concerns here are schedule-driven: do we really want to be wringing out a new contrib module, to the point where it will run everywhere, before we can release 7.1? Hrmmm ... just a thought here, but how about a potential 'interactive' regression test, where it asks if you want to run regress on GiST? If so, do it, if not, ignore it ... ?