Thread: Inprise/Borland releasing Interbase as Open source
FYI: SCOTTS VALLEY, Calif., Jan. 3 /PRNewswire/ -- Inprise Corporation (Nasdaq: INPR) today announced that it is jumping to theforefront of the Linux database market by open-sourcing the beta version of InterBase 6, the new version of its SQL database.InterBase will be released in open-source form for multiple platforms, including Linux, Windows NT, and Solaris. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > InterBase 6, the new version of its SQL database. InterBase will be > released in open-source form for multiple platforms, including Linux, I wonder just how 'open' it will be, license-wise..... Nice thing about PostgreSQL -- it doesn't get any more open than the BSD license. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Bruce Momjian wrote: > > FYI: > > SCOTTS VALLEY, Calif., Jan. 3 /PRNewswire/ -- Inprise Corporation > (Nasdaq: INPR) today announced that it is jumping to the forefront of > the Linux database market by open-sourcing the beta version of > InterBase 6, the new version of its SQL database. InterBase will be > released in open-source form for multiple platforms, including Linux, > Windows NT, and Solaris. > Seems we are starting to get some serious competition ;) AFAIK, they cover more or less the same features (except domains which we don't have) BTW, it also says: The source code for InterBase 6 is scheduled to be published during the first part of the year 2000. Chould this "part" be 1/2, 1/3, 1/4, 1/12 (or 1/1) ? ------------ Hannu
I wish this announcement had been made a few months ago!! We have several developers porting our server software to PostgreSQL. Although we like PostgreSQL, we have run into a number of memory leaks and bugs - something we never encountered with Interbase. Now Interbase is going open source, we will discontinue the PostgreSQL development effort. Interbase is such a well written DBMS, it doesn't make sense to continue. You guys have done a great job - but, frankly, IB is better. Steve Bruce Momjian wrote: > FYI: > > SCOTTS VALLEY, Calif., Jan. 3 /PRNewswire/ -- Inprise Corporation > (Nasdaq: INPR) today announced that it is jumping to the forefront of > the Linux database market by open-sourcing the beta version of > InterBase 6, the new version of its SQL database. InterBase will be > released in open-source form for multiple platforms, including Linux, > Windows NT, and Solaris. > > -- > Bruce Momjian | http://www.op.net/~candle > maillist@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ************
On Mon, 3 Jan 2000, Stephen Birch wrote:
> I wish this announcement had been made a few months ago!! We have
> several developers porting our server software to PostgreSQL.
> Although we like PostgreSQL, we have run into a number of memory leaks
> and bugs - something we never encountered with Interbase.
What version of PostgreSQL? Did the problem reports you sent in not
improve the situation?
> Now Interbase is going open source, we will discontinue the PostgreSQL
> development effort. Interbase is such a well written DBMS, it doesn't
> make sense to continue.
Two points...when will Interbase go open source? Right now they've
announced the intention to do so, and even given a very brood time
frame...but, when is it going to happen. two...what says Interbase will
continue to be "as good" when becomes open source and they are no longer
making any money on it?
> You guys have done a great job - but, frankly, IB is better.
In what ways?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 3 Jan 2000, Stephen Birch wrote: > You guys have done a great job - but, frankly, IB is better. > > Steve wtf ? what sort of lame remark/incentive is that ? gimme a break being amongst the multitudes who use pg dayin/dayout i hate tirekickers that say rubbish like 'such and such is better' or 'if you do such and such' having been down this path many times over the years myself, the last thing the engineers working on pg need is to hear those sort of negative comments. just my $0.02c knowing how hard everyone works on pg and it is superb! /Torqumada Norman Widders - Paladin Corporation Pty Ltd. ACN: 081-191-611 The lyf so short, the craft so long to lerne - Chaucer NIC: NW83-AU OpenBSD, FreeBSD, Solaris, SCO, Debian Software Engineering: c/c++/perl/sql/eiffel/pascal/haskell Ph: +612 9835-4782 Fax: +612 9864-0487 Mobile: 0416-207-857 Powered by Symetric Multiple Processors running on FreeBSD 3.4/SMP -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (FreeBSD) Comment: Made with pgp4pine iEYEARECAAYFAjhxr4oACgkQfpbFlIYNi7dHxwCcCYDevE7ev1VE5XS0cAz5L266 VtwAoIfdLqeqEw2JEVZXW4tyPnp3rsLn =BzpQ -----END PGP SIGNATURE-----
Stephen Birch wrote: > > I wish this announcement had been made a few months ago!! We have several > developers porting our server software to PostgreSQL. Although we like > PostgreSQL, we have run into a number of memory leaks and bugs - something > we never encountered with Interbase. > > Now Interbase is going open source, we will discontinue the PostgreSQL > development effort. Interbase is such a well written DBMS, it doesn't make > sense to continue. The announcement said that IB version 6 _beta_ is going to be open source, without specifying what kind of license it will have. It could very well be something like SCL (i.e. you can have the source, but what you can do with it is quite limited). If you just need a beer-kind-of-free database, you may be better off with using Sybase or IB v.4 I suspect that the move to open-source it is at least partly an effort to fix "a number of memory leaks and bugs" ;) ------------ Hannu
Stephen Birch <sbirch@ironmountainsystems.com> wrote: > Now Interbase is going open source, we will discontinue the PostgreSQL > development effort. Interbase is such a well written DBMS, it doesn't make > sense to continue. You might want to wait to see what they mean by "open source". They might mean GPL, BSD, MPL or they could be rolling their own vanity license that'll take months to debug. They also might go the bogus "open source" route, ala Sun's "Community Source License". Open source projects are a tricky business... if they don't do it right, they won't attract the critical mass of developers they need to keep the project going (yes, old code never dies, but it does bitrot away...).
Stephen Birch wrote: > > I wish this announcement had been made a few months ago!! We have several > developers porting our server software to PostgreSQL. Although we like > PostgreSQL, we have run into a number of memory leaks and bugs - something > we never encountered with Interbase. > > Now Interbase is going open source, we will discontinue the PostgreSQL > development effort. Interbase is such a well written DBMS, it doesn't make > sense to continue. > > You guys have done a great job - but, frankly, IB is better. Just been porting our app to Oracle. It took me 3 days to install, and an extreme amount of frustration ie. jre1.1.6 is hardwired in so you have to have it to install, oci apps core when dynamically linked, column size (linesize) set to greater than 125 causes a core when describing an object in sqlplus,... Will look at IB when it comes around, but right now give me Postgres anyday! -------- Regards Theo
The Hermit Hacker wrote:
> On Mon, 3 Jan 2000, Stephen Birch wrote:
>
> > I wish this announcement had been made a few months ago!! We have
> > several developers porting our server software to PostgreSQL.
> > Although we like PostgreSQL, we have run into a number of memory leaks
> > and bugs - something we never encountered with Interbase.
>
> What version of PostgreSQL? Did the problem reports you sent in not
> improve the situation?
I haven't seen that many. And what kind of a project leader must it be, that a simple announcement causes the
workof several programmers over months (sounds at least like a man-year) to be thrown away? IMHO the kind of PL,
companieslike M$ are targeting with their huge amount of announcements.
> > Now Interbase is going open source, we will discontinue the PostgreSQL
> > development effort. Interbase is such a well written DBMS, it doesn't
> > make sense to continue.
>
> Two points...when will Interbase go open source? Right now they've
> announced the intention to do so, and even given a very brood time
> frame...but, when is it going to happen. two...what says Interbase will
> continue to be "as good" when becomes open source and they are no longer
> making any money on it?
Since it's the toplevel story on www.borland.com, I think it'll really happen soon. And I also think they intend
tocontinue making money on it, just not by selling DB-licenses any more. They have a rich set of development
toolsetc. they can sell anyway. And in many projects I've seen that it's never a bad choice not to mixup too many
hardware/softwarevendors (they'll all point to each other as soon as problems arise). So it's a big PRO for their
applicationsand tools, if you'll get the DB they use for free. And it's your decision to spend money when going
intoproduction to buy commercial support (what I expect they'll offer).
Another point is this. As long as I know Postgres, a couple of features had been added just because some user
neededit. And they are supported and kept alive. Do they have some proposal on that? How will they deal with some
feature-patchsent in?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
I've since gotten an email from Stephen in response to his comments, and I
think that when he wrote his original, he needed his morning cup of coffee
(or equivalent), since it came over alot heavier then what he email'd
me...
A quick summary:
They didn't report the memory leaks...they fixed them and uploaded
patches, which have been accepted and commit'd
A few problems couldn't be reproduced, and, therefore, left
unreported. I wish ppl would report anyway, as someone else might be
coming across this, finding it also non-reproducable and might have some
data to add :(
The only one that is left outstanding right now has to do with:
"However, the biggest problem was reported recently, see "HEAP_MOVED_IN during
vacuum" posted on Saturday, no replies" ...
Anyone have any comments on that last one?
On Tue, 4 Jan 2000, Jan Wieck wrote:
> The Hermit Hacker wrote:
>
> > On Mon, 3 Jan 2000, Stephen Birch wrote:
> >
> > > I wish this announcement had been made a few months ago!! We have
> > > several developers porting our server software to PostgreSQL.
> > > Although we like PostgreSQL, we have run into a number of memory leaks
> > > and bugs - something we never encountered with Interbase.
> >
> > What version of PostgreSQL? Did the problem reports you sent in not
> > improve the situation?
>
> I haven't seen that many. And what kind of a project leader must it be,
> that a simple announcement causes the work of several programmers over
> months (sounds at least like a man-year) to be thrown away? IMHO the
> kind of PL, companies like M$ are targeting with their huge amount of
> announcements.
>
>
> > > Now Interbase is going open source, we will discontinue the PostgreSQL
> > > development effort. Interbase is such a well written DBMS, it doesn't
> > > make sense to continue.
> >
> > Two points...when will Interbase go open source? Right now they've
> > announced the intention to do so, and even given a very brood time
> > frame...but, when is it going to happen. two...what says Interbase will
> > continue to be "as good" when becomes open source and they are no longer
> > making any money on it?
>
> Since it's the toplevel story on www.borland.com, I think it'll really
> happen soon. And I also think they intend to continue making money on
> it, just not by selling DB-licenses any more. They have a rich set of
> development tools etc. they can sell anyway. And in many projects I've
> seen that it's never a bad choice not to mixup too many
> hardware/software vendors (they'll all point to each other as soon as
> problems arise). So it's a big PRO for their applications and tools, if
> you'll get the DB they use for free. And it's your decision to spend
> money when going into production to buy commercial support (what I
> expect they'll offer).
>
> Another point is this. As long as I know Postgres, a couple of features
> had been added just because some user needed it. And they are supported
> and kept alive. Do they have some proposal on that? How will they deal
> with some feature-patch sent in?
>
>
> Jan
>
> --
>
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me. #
> #========================================= wieck@debis.com (Jan Wieck) #
>
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
At 10:39 PM 1/3/00 -0400, The Hermit Hacker wrote: >On Mon, 3 Jan 2000, Stephen Birch wrote: (HH): >Two points...when will Interbase go open source? Right now they've >announced the intention to do so, and even given a very brood time >frame...but, when is it going to happen. two...what says Interbase will >continue to be "as good" when becomes open source and they are no longer >making any money on it? They say they'll continue to sell it via their traditional channels and sell support, too. So it's not really clear what open-source means in this context. Open-source doesn't have to mean the disappearance of license fees... >> You guys have done a great job - but, frankly, IB is better. > >In what ways? Outer joins, for one. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
Don Baccus wrote: > At 10:39 PM 1/3/00 -0400, The Hermit Hacker wrote: > >On Mon, 3 Jan 2000, Stephen Birch wrote: > > (HH): > >Two points...when will Interbase go open source? Right now they've > >announced the intention to do so, and even given a very brood time > >frame...but, when is it going to happen. two...what says Interbase will > >continue to be "as good" when becomes open source and they are no longer > >making any money on it? > > They say they'll continue to sell it via their traditional channels > and sell support, too. They say: "The source code for InterBase 6 is scheduled to be published during the first part of the year 2000. The company also announced it plans to continue to sell and support InterBase 5.6 through normal distribution channels..." If I understand seems they refer to previous version i.e. InterBase ver. 5.6 but version 6 will be open source, maybe... > So it's not really clear what open-source > means in this context. Open-source doesn't have to mean the disappearance > of license fees... > > >> You guys have done a great job - but, frankly, IB is better. > > > >In what ways? > > Outer joins, for one. > > - Don Baccus, Portland OR <dhogaza@pacifier.com> > Nature photos, on-line guides, Pacific Northwest > Rare Bird Alert Service and other goodies at > http://donb.photo.net. > > ************
The Hermit Hacker <scrappy@hub.org> writes:
> "However, the biggest problem was reported recently, see "HEAP_MOVED_IN
> during vacuum" posted on Saturday, no replies" ...
> Anyone have any comments on that last one?
I replied to it --- not with any useful ideas I'm afraid, just asking
for more info. But if Stephen is claiming he was ignored, then he's
not reading his email...
regards, tom lane
At 04:29 PM 1/4/00 +0100, Jose Soares wrote: >Don Baccus wrote: >> They say they'll continue to sell it via their traditional channels >> and sell support, too. > >They say: >"The source code for InterBase 6 is scheduled to be published during the first >part of the year 2000. >The company also announced it plans to continue to sell and support InterBase >5.6 through normal distribution channels..." > >If I understand seems they refer to previous version i.e. InterBase ver. 5.6 >but version 6 will be open source, maybe... So they'll sell 5.6 but maybe 6 will be free? Strange. Rumor on Slashdot is that they've lost their key developers (a month or so ago). And (in response to Jan), yeah, I know outer joins are scheduled to be completed in 7.1. Personally, the interbase news leaves me yawning. Postgres, since 6.5, is meeting my needs just fine. BTW, it appears that they have "multi-generational" concurrency control, which sounds very much like MVCC. Indeed, the white paper describing it makes it sound as though the basic strategy for storing tuples with transaction ids (the "generations") is kinda similar to PostgreSQL. They support dirty reads and some ways to specify which "generation" to read from. Might be some ideas there worth looking at for future PostgreSQL work... Keep in mind that I spent no more than 15 minutes trucking around their site and docs so I picked up no more than a very, very surface impression of stuff. (in other words, my quick impressions may be very innaccurate). - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
Don Baccus wrote:
>
>
> So they'll sell 5.6 but maybe 6 will be free? Strange. Rumor on Slashdot
> is that they've lost their key developers (a month or so ago).
If THAT's the case, man, then they try to get back experienced programmers for development and support for free
viathe internet. Then it would take some time until they're able to offer professional support.
>
>
> And (in response to Jan), yeah, I know outer joins are scheduled
> to be completed in 7.1. Personally, the interbase news leaves me
> yawning. Postgres, since 6.5, is meeting my needs just fine.
Was Marc IIRC. Anyway, most of our proposed features appear in time or with a 25-50% overrun. What's absolutely
strongfor free+open software. And moreover, almost every serious bug, that is fixable without destroying anything
else,get's fixed in a couple of days or weeks. The reason for the latter is, that we have a fistfull of programmes
who work for years now on the code. Some of us since the release from Berkeley. That are key developers, who know
intuitivelyinto what region of the code to dive if some strange misbehaviour is reported.
So if Inprise really lost them, they have a severe problem.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> Was Marc IIRC. Anyway, most of our proposed features appear in time or > with a 25-50% overrun. What's absolutely strong for free+open software. > And moreover, almost every serious bug, that is fixable without > destroying anything else, get's fixed in a couple of days or weeks. The > reason for the latter is, that we have a fistfull of programmes who > work for years now on the code. Some of us since the release from > Berkeley. That are key developers, who know intuitively into what > region of the code to dive if some strange misbehaviour is reported. > > So if Inprise really lost them, they have a severe problem. Another _big_ issue is how clean the code is. MySQL, for example, probably loses tons of people because their code is so poorly designed, and just plain ugly to me. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
At 02:50 PM 1/4/00 -0500, Bruce Momjian wrote: >Another _big_ issue is how clean the code is. MySQL, for example, >probably loses tons of people because their code is so poorly designed, >and just plain ugly to me. I'll have to say that the Postgres code's quite easy to follow, at least at the "grasp-the-big-picture" level at which I've been reading it on a casual, off-and-on basis. Understanding it well enough to contribute - well, that's another issue 'cause by its nature it is a fairly complex beast! - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
> At 02:50 PM 1/4/00 -0500, Bruce Momjian wrote: > > >Another _big_ issue is how clean the code is. MySQL, for example, > >probably loses tons of people because their code is so poorly designed, > >and just plain ugly to me. > > I'll have to say that the Postgres code's quite easy to follow, at > least at the "grasp-the-big-picture" level at which I've been reading > it on a casual, off-and-on basis. Understanding it well enough to > contribute - well, that's another issue 'cause by its nature it is > a fairly complex beast! Totally true. Education is very important, and clean coding helps with that. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Jan Wieck wrote:
> I haven't seen that many. And what kind of a project leader must it be,
> that a simple announcement causes the work of several programmers over
> months (sounds at least like a man-year) to be thrown away? IMHO the
> kind of PL, companies like M$ are targeting with their huge amount of
> announcements.
>
Ouch - that hurt.
Let me address the kind of project manager we are talking about here by looking
back at the decision to move from MS to Linux:
In fact, the move to Linux meant throwing away about 10 man years worth of
work on WIN32. However, the cost savings to my employer were substantial as
customer support issues disappeared overnight once the port was done. However,
the 10 MY were not discarded over a single announcement, we watched Linux and
experimented with it for about 3 years before starting the port.
To see why we would abort development on a PostgreSQL port of our servers
because of the IB announcement, you must understand why we financed the port to
PG in the first place. When GNU changed the C run time library to 2.1 (again),
it broke our IB 4.0 based software and prevented us from moving forward to the
current SuSE 6.2 (at the time) release. We knew the IB problem could be fixed
in an hour or two by recompiling the IB code - but we did not have the source
and Borland considered 4.0 dead.
In itself, this problem did not justify authorizing the PG development - but we
felt it was indicative of future problems with IB. Hence we started to
research PG to see if it was a suitable replacement. Investing in PG made me
damn nervous because I failed to locate example sites trusting it with mission
critical work. In fact, I was convinced by reading the discussion groups and
noting the extremely high caliber of people working on PG and also the
incredible integrity these guys have. Evenb though they don't make a dime from
PostgreSQL, they really, really care about the software and its users.
We now have PG based servers under test in the lab and are still solving PG
issues before releasing alpha code. Of course, the IB announcement forces us
to rethink the issue.
As for me being influenced by marketing literature, especially from MS - you
are way off mark.
By the way, I was the idiot that specified NT to our customer base in the first
place - I consider that to be the single worst decision of my successful 20
year computing career.
One final point, I live in a 100% commercial world. In the capacity of my
work, I am not concerned about the free software ethos, nor do I care if
software is free or not (as in beer) - I just need to deploy solutions that
work.
Steve
{{{{{{{{ {{{{{ 1 hour of real time passed here }}}}}}}}}
Since writing the above, I was called to attend a telecon with my manager and
the ITS managers from our two biggest customers to discuss exactly this issue.
The decision has been made to deploy the PostgreSQL based server. We all
agreed that whatever happens to Interbase, the personal commitment by the
PostgreSQL folks is not likely to dry up. Hence the code will continue to
improve over time. I believe that they clearly understand how important
reliability is to a database server.
There is a good chance that the Borland decision will have a benificial ripple
effect on PG as other engineers turn their attention to Open Source
alternatives.
Wish us luck, we will load the new software on our customers' servers for a FOT
(field operational test) next week.
Steve
On Tue, 4 Jan 2000, Stephen Birch wrote:
> By the way, I was the idiot that specified NT to our customer base in
> the first place - I consider that to be the single worst decision of
> my successful 20 year computing career.
Ouch, that must have hurt :(
> Since writing the above, I was called to attend a telecon with my
> manager and the ITS managers from our two biggest customers to discuss
> exactly this issue. The decision has been made to deploy the
> PostgreSQL based server. We all agreed that whatever happens to
> Interbase, the personal commitment by the PostgreSQL folks is not
> likely to dry up. Hence the code will continue to improve over time.
> I believe that they clearly understand how important reliability is to
> a database server.
>
> There is a good chance that the Borland decision will have a
> benificial ripple effect on PG as other engineers turn their attention
> to Open Source alternatives.
>
> Wish us luck, we will load the new software on our customers' servers
> for a FOT (field operational test) next week.
Good luck, and keep us informed as to how things are going ... :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> Since writing the above, I was called to attend a telecon with my manager and > the ITS managers from our two biggest customers to discuss exactly this issue. > The decision has been made to deploy the PostgreSQL based server. We all > agreed that whatever happens to Interbase, the personal commitment by the > PostgreSQL folks is not likely to dry up. Hence the code will continue to > improve over time. I believe that they clearly understand how important > reliability is to a database server. All's well that end's well... I have been very impressed over the three years of work on PostgreSQL that everything is done is such a civilized matter. I mention that in my book and in the development history. Not sure how we have achieved this, but we certainly have. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > Since writing the above, I was called to attend a telecon with my > > manager and the ITS managers from our two biggest customers to discuss > > exactly this issue. The decision has been made to deploy the > > PostgreSQL based server. We all agreed that whatever happens to > > Interbase, the personal commitment by the PostgreSQL folks is not > > likely to dry up. Hence the code will continue to improve over time. > > I believe that they clearly understand how important reliability is to > > a database server. > > > > There is a good chance that the Borland decision will have a > > benificial ripple effect on PG as other engineers turn their attention > > to Open Source alternatives. > > > > Wish us luck, we will load the new software on our customers' servers > > for a FOT (field operational test) next week. > > Good luck, and keep us informed as to how things are going ... :) Let me add we are planning a 7.0 release in the next few months that improves reliability and adds new features. You can actually try the snapshot if you want to see how we are doing. 6.5.* is based in code that solidified in June of 1999, which is ages ago in PostgreSQL time. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Stephen Birch wrote:
> Jan Wieck wrote:
>
> > I haven't seen that many. And what kind of a project leader must it be,
> > that a simple announcement causes the work of several programmers over
> > months (sounds at least like a man-year) to be thrown away? IMHO the
> > kind of PL, companies like M$ are targeting with their huge amount of
> > announcements.
> >
>
> Ouch - that hurt.
Pardon for beeing that harsh, but similar to you (as Marc said you haven't had your first cup of coffee), I
missedmy required amount of beer :-)
> We now have PG based servers under test in the lab and are still solving PG
> issues before releasing alpha code. Of course, the IB announcement forces us
> to rethink the issue.
That sounds totally different to your first message. This is definitely a PUSH BREAK for possible limitation of
loss.
> Since writing the above, I was called to attend a telecon with my manager and
> the ITS managers from our two biggest customers to discuss exactly this issue.
> The decision has been made to deploy the PostgreSQL based server. We all
> agreed that whatever happens to Interbase, the personal commitment by the
> PostgreSQL folks is not likely to dry up. Hence the code will continue to
> improve over time. I believe that they clearly understand how important
> reliability is to a database server.
Great news. Be sure, I'll be one of the last rats leaving the ship.
> There is a good chance that the Borland decision will have a benificial ripple
> effect on PG as other engineers turn their attention to Open Source
> alternatives.
There aleady is a noticeable turn in attention. Creative recently decided to put their SB-Live! drivers for
Linuxunder GPL (after they had severe problems with IRQ and DMA handling at least in the SMP environment). One
monthlater, the driver totally fit's my needs. Well, they're a hardware vendor, primarily selling their cards to
makemoney.
OTOH, I'm an SAP R/3 base consultant for years now. And all these DB runtime license discussions are annoying.
SAPneeds about 2-3 months to port R/3 to a new database. But they need another year or so to ship it due to their
internalquality assurance policy. And it's a not to underestimate efford impact to support it in the future. The
same applies to the OS corner, but they decided to port R/3 to Linux anyway, because coupling the benefits of the
UNIXworld (WRT administration issues) with the low cost level of PC hardware, is definitely worth the above
efford.
So I wouldn't be surprised if SAP, one of the biggest software vendors worldwide, would decide to support an
opensource database too at some point in the future. And something like that might be the intention of Inprise.
Aswe both know, a customer usually keeps his database world consistent to be able to share knowledge inside the
company.So if they can save tenth of thousands of dollars DB-license fee per year (a usually small fee in the SAP
market)when moving to an open source database, they will decide to do so. And at that point, they'll need to port
theirintranet-, internet- and other solutions as well.
If it's not true (as someone rumored) that Inprise lost the key developers, that'd be the point.
> Wish us luck, we will load the new software on our customers' servers for a FOT
> (field operational test) next week.
Report any problems ASAP, and we'll help to make it a success-story.
> Steve
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
I have now created a test case that demonstrate the HEAP_MOVED_IN during vacuum problem. Since the tar ball is 182k - I put it on an ftp site instead of mailing it. You can grab it from the following location: http://www.ironmountainsystems.com/heap_moved_in/ The tar ball contains two files - a shell script (show_bug) and a pg_dump dump. The shell script does the following using the dump file: 1. Create database ntis 2. Create table msg and populate it. 3. Use trim() twice. 4. Vacuum. The three interesting commands reside at the end of ntis.dmp: update msg set description = trim(description); update msg set owner = trim(owner); vacuum; when the script "show_bug" is run, we get the following output: CREATE DATABASE You are now connected to database ntis. CREATE UPDATE 12069 UPDATE 12069 ERROR: HEAP_MOVED_IN was not expected One interesting point: if either one of the trim operations is omitted, vacuum does not give the HEAP_MOVED_IN error. I also notice that if you change ntis.dmp so a vacuum is done between the two, the problem goes away. Any ideas? Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > "However, the biggest problem was reported recently, see "HEAP_MOVED_IN > > during vacuum" posted on Saturday, no replies" ... > > > Anyone have any comments on that last one? > > I replied to it --- not with any useful ideas I'm afraid, just asking > for more info. But if Stephen is claiming he was ignored, then he's > not reading his email... > > regards, tom lane > > ************
Stephen Birch <sbirch@ironmountainsystems.com> writes:
> I have now created a test case that demonstrate the HEAP_MOVED_IN during
> vacuum problem.
Using this script, I see no failure under either REL6_5_PATCHES or
current branch on HPUX 10.20 --- but I do see it in current sources
on a Linux box! Platform-dependent problem, evidently. Will start
digging.
Stephen, many thanks for creating a small, reproducible example.
I know that's often the hardest part of finding a bug...
regards, tom lane
> -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Stephen Birch > > I have now created a test case that demonstrate the HEAP_MOVED_IN during > vacuum problem. Since the tar ball is 182k - I put it on an ftp site > instead of mailing it. > > You can grab it from the following location: > > http://www.ironmountainsystems.com/heap_moved_in/ > The following patch seems to fix your case. However I'm not sure it's a right solution. Regards. Hiroshi Inoue Inoue@tpf.co.jp Index: commands/vacuum.c =================================================================== RCS file: /home/cvs/pgcurrent/backend/commands/vacuum.c,v retrieving revision 1.18 diff -c -r1.18 vacuum.c *** commands/vacuum.c 2000/01/05 03:05:35 1.18 --- commands/vacuum.c 2000/01/10 02:39:35 *************** *** 1049,1054 **** --- 1049,1055 ---- *idcur; int last_fraged_block, last_vacuum_block, + last_movedin_block, i = 0; Size tuple_len; int num_moved, *************** *** 1084,1089 **** --- 1085,1091 ---- vacuumed_pages = vacuum_pages->vpl_num_pages - vacuum_pages->vpl_empty_end_pages; last_vacuum_page = vacuum_pages->vpl_pagedesc[vacuumed_pages - 1]; last_vacuum_block= last_vacuum_page->vpd_blkno; + last_movedin_block = 0; Assert(last_vacuum_block >= last_fraged_block); cur_buffer = InvalidBuffer; num_moved= 0; *************** *** 1097,1102 **** --- 1099,1107 ---- /* if it's reapped page and it was used by me - quit */ if (blkno == last_fraged_block&& last_fraged_page->vpd_offsets_used > 0) break; + /* couldn't shrink any more if this block has MOVED_INd tuples - quit */ + if (blkno == last_movedin_block) + break; buf = ReadBuffer(onerel, blkno); page = BufferGetPage(buf); *************** *** 1477,1482 **** --- 1482,1489 ---- newtup.t_datamcxt = NULL; newtup.t_data = (HeapTupleHeader) PageGetItem(ToPage,newitemid); ItemPointerSet(&(newtup.t_self), vtmove[ti].vpd->vpd_blkno, newoff); + if (vtmove[i].vpd->vpd_blkno > last_movedin_block) + last_movedin_block = vtmove[i].vpd->vpd_blkno; /* * Set t_ctid pointing to itself for last tuple in *************** *** 1610,1615 **** --- 1617,1624 ---- newtup.t_data = (HeapTupleHeader) PageGetItem(ToPage, newitemid); ItemPointerSet(&(newtup.t_data->t_ctid),cur_page->vpd_blkno, newoff); newtup.t_self = newtup.t_data->t_ctid; + if (cur_page->vpd_blkno > last_movedin_block) + last_movedin_block = cur_page->vpd_blkno; /* * Mark old tuple as moved_off by vacuum and store vacuum XID
Stephen Birch <sbirch@ironmountainsystems.com> writes:
> I have now created a test case that demonstrate the HEAP_MOVED_IN during
> vacuum problem.
OK, I've sussed it. Dunno if you want the details, but briefly: the
code was using the last element of a list of target pages (pages that
had room to insert more tuples) as a sentinel point to know when to
stop trying to move tuples out of source pages. But there was also
an optimization in there to remove target pages from the target list
as soon as they got full (so as not to keep checking them). Sure
enough, with the right data pattern it was possible to remove the
last modified page from the target-page list before the source loop
got to it, and then everything falls over. I'm surprised we haven't
heard more complaints about this, actually --- it doesn't look like
the failure should be all that unlikely.
I have committed what I think is a proper fix into current sources,
but I don't really think it should be trusted until it's been through
a beta test cycle. Instead, attached is a very low-risk patch that
just dikes out the code that tries to remove target pages early.
This will result in some marginal slowdown when vacuuming huge
relations, but I think it should be safe to plug into production
6.5.* servers.
Thanks again for the narrowly focused test case --- I suspect you
put quite a bit of time into developing it...
regards, tom lane
*** src/backend/commands/vacuum.c.orig Tue Jan 4 12:27:26 2000
--- src/backend/commands/vacuum.c Sun Jan 9 23:16:10 2000
***************
*** 1253,1258 ****
--- 1253,1259 ---- { if (!vc_enough_space(to_vpd, tlen)) {
+ #if 0 /* this code is broken */ if (to_vpd != last_fraged_page &&
!vc_enough_space(to_vpd, vacrelstats->min_tlen)) {
***************
*** 1263,1268 ****
--- 1264,1270 ---- num_fraged_pages--; Assert(last_fraged_page
==fraged_pages->vpl_pagedesc[num_fraged_pages - 1]); }
+ #endif for (i = 0; i < num_fraged_pages; i++) {
if (vc_enough_space(fraged_pages->vpl_pagedesc[i], tlen))
***************
*** 1517,1522 ****
--- 1519,1525 ---- WriteBuffer(cur_buffer); cur_buffer = InvalidBuffer;
+ #if 0 /* this code is broken */ /* * If no one
tuplecan't be added to this page - * remove page from fraged_pages. - vadim 11/27/96
***************
*** 1534,1539 ****
--- 1537,1543 ---- num_fraged_pages--; Assert(last_fraged_page ==
fraged_pages->vpl_pagedesc[num_fraged_pages- 1]); }
+ #endif } for (i = 0; i < num_fraged_pages; i++) {
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> The following patch seems to fix your case.
> However I'm not sure it's a right solution.
That looks like nearly the same logic that I arrived at, although
what I committed included some additional code cleanups. As I said
in my prior message, I don't fully trust it yet --- but I am glad
you came to the same conclusion.
regards, tom lane
I still can't believe how fast you guys are, but would like to thank you. If I understood the vacuum logic, I would check your fixes, but it is still black magic to me!! I did try the new code against the full database and found no problems. As far as I can tell, you found it. Thanks again. Steve Tom Lane wrote: > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > The following patch seems to fix your case. > > However I'm not sure it's a right solution. > > That looks like nearly the same logic that I arrived at, although > what I committed included some additional code cleanups. As I said > in my prior message, I don't fully trust it yet --- but I am glad > you came to the same conclusion. > > regards, tom lane