Note that I said "shareholders" and not "stockholders". MySQL is private, but they got something like $20M in VC not too long ago. If you give charity to MySQL AB, you're just lining the pockets of the VCs, who aren't in it for the spirit of the GPL. I recommend the FSF or some other organized group that can effectively develop software -- and give you a tax break. Here are some of the places I have given money:
- FreeBSD: Interestingly, I gave them money before I even really used FreeBSD, because at the time, they needed small donations. Now I use it in production and I love it! - PostgreSQL - FreeNet: I regret donating money to FreeNet. I sent them like $10. My intention at the time was to promote free speech on the internet. When I figured out that it's really nothing but horrible filth, I decided that I didn't want them using anything of mine to support that kind of content. The internet is free enough, hopefully. - LinuxFund: I actually just use a mastercard, and it builds up money in the linuxfund account. I think they're still looking for a good place to spend it, so I would say they're not very organized. But I suppose they'll probably end up just kicking it off to the FSF or something, so it should work out.
Next time I make a donation, it will probably be to FreeBSD, FSF, OpenBSD (gotta love openssh), or PostgreSQL.
By the way, usually increasing your eating frequency is good for losing weight and gaining muscle (not to mention general health & feeling good). I suppose whatever works for you. I don't gain muscle easily either.
I agree with you in general, but your example is just not working for me. Typically, you would use a "float" datatype for an extremely large year, not a timestamp/date. MySQL has a float datatype.
But in general, I agree that type extensibility is a vital component of an RDBMS.
However, because of Oracle's hostile move, I tend to think of it as though Oracle bought MySQL AB itself. It's not exactly the same, but it certainly could turn out that way.
=> select '1000000-10-10 10:10:10'::timestamp; ERROR: timestamp out of range: "1000000-10-10 10:10:10"
I'm a big PostgreSQL fan, but you're just being rediculous if you ask MySQL to accept arbitrarily large years. It should error out and be done.
How many scientific applications require you to know what day of the week Oct 18, 20000000000000005 is?
I think you're looking for the "float" datatype. And if you're not, you really should make your own type, because your needs are obviously very specific.
They are a commercial company. It only makes sense for people to donate to the cause itself, that is, the actual development of the MySQL DB product; not the shareholders behind a company that is associated with the cause. How would you feel if you donated some money, and then the investors liquidated or changed the business model? Your charity just went to some suits.
I am willing to skip a meal
It isn't a hunger strike, dude. At least make enough use of the bounties of modern society to eat 3 meals per day!
MySQL can only go through so many "rebirths" (MyISAM, BDB, InnoDB, ____ ) before the users figure out that the only thing that's really "MySQL" is the language.
And people don't make new database installations based on syntax.
Now, MySQL doesn't really compete with Oracle *yet.*
Indirectly, they do. You could look at it like Oracle is nipping it in the bud, I suppose.
Oracle certainly doesn't want a company running around to a bunch of people saying "Database" and "$495" in the same sentence.
And they certainly don't want a lot of casual database users who shift the market away from Oracle's traditional database model of "data integrity, expensive DBAs, referential integrity, expensive DBAs, redundancy, and expensive DBAs", to MySQL's model of "throw your data here, and when you ask for it, we'll send it back to you".
The GPL branch of the code, however, would be able to continue essentially unchanged
By who? Not by MySQL AB. It takes a long time to make a new community work effectively.
MySQL AB is between a rock and a hard place, I think we can agree here. If Oracle cuts off InnoDB from commercial licensing, MySQL will stop developing/supporting it, it's only a matter of time. They simply can't have a GPL version that's better than their commercial version. Then, without transactions or RI, their "enterprise-ness" and usefulness will be called into question.
So that leaves the community. But the community is too wrapped around MySQL AB to function on it's own just yet. That will take time.
And that time is precisely what Oracle doesn't want MySQL to have. If the development of MySQL DB is set back by 12-18 months, that will surely be a victory for Oracle, who will secure a strong lead ahead of the most popular open source database. The wind will be stolen from the 5.0 release, and another few rounds of businessmen will make long-term commitments to Oracle (in the form of licenses and hardware).
The Innobase purchase/ MySQL debacle is really an indictment of their business and development model.
MySQL AB is at the epicenter of development of MySQL DB, and requires copyright transfers for any outside changes. Paid developers at one small company largely create and support the entire database. Some users get a sense of security that there is "one person to go to", and a single focused business behind it. In some ways this business model worked well... their marketing was very successful, and the database might be described as more "unified" than, for example, PostgreSQL, where things like FTS and replication are independently developed (which is actually good, but can confuse users who think that "it's not good enough to be included").
However, the PostgreSQL development model has been working very effectively, not dependent on any one company. A short list of contributors includes the likes of Fujitsu, Sun, Affilias (manages all.org and.info), Software Research Associates (SRA), Red Hat, Aglio DB, EnterpriseDB (won LinuxWorld "Best Database Solution" last year, beating Oracle), Command Prompt (I probably left a lot out).
When Great Bridge hired a bunch of the PostgreSQL developers, then got scared and pulled funding, the developers went back to the community. The community was the core to begin with, and development continued as always. Other companies came in to support it, and development has never been stronger. More importantly, the community has never been stronger.
The reason MySQL DB users are concerned, even though the source is GPL, is because MySQL DB is heavily dependent on MySQL AB. If MySQL is forced out by Oracle, what's left aside from some source code? There are a lot of users who would rally and try to build a community. But building a community to support an RDBMS takes more than just a few good programmers. It takes years to build the kind of community that works like the PostgreSQL Global Development Group (PGDG). It takes programmers, organizers, advocates, managers, advocates, support channels, channels for accepting new developers (for instance, if a company wants to pay for a feature), decision makers, and arbitrators (to prevent too much forking). And it takes a lot of time to figure out who does what, and when they do it, and how to reconcile conflicts or scheduling difficulties, how to work as a team so that work is integrated properly and time is not wasted.
If someone has a proposal for a feature, who do they ask so that it's heard? Will a reliable decision be made about whether/when to progress? Who should step up and program? Who will open the channels of communication between the programmer and any other programmers working in similar code areas? Who will enforce project "standards"? Who will devise the standards? Does it go in this release or wait 'til the next? When is feature freeze? Who determines what quality level constitutes a release? Should the patch be backported? If it breaks any compatibility, who will devise a proper release timeline to avoid hurting existing users too much?
It really takes a long time to build those conventions and organize people into a functional development group. MySQL DB users can only hope that MySQL AB is still around for a while. If MySQL AB goes the way of Great Bridge, MySQL DB may be left in chaos. In the meantime, start forming a community that can operate outside of MySQL AB. The monolithic development/business model seems to be in question right now.
they could elect to kill InnoDB at some future point. I just don't see how this is a win for FOSS. To me, this isn't a likely danger, though.
I think it's very likely that Oracle does just that. Oracle wins on several fronts:
(1) Set back a competitor by a lot, possibly completely knocking it out of some markets. (2) Cause more OSS FUD: "What will happen to your open source vendor? It could evaporate tomorrow. Stick with Oracle, who will be there for you." (3) Shift the market back toward the mentality of traditional relational databases, where there is a lot of emphasis on data integrity constraints, and expensive DBAs, and less emphasis on casual users.
MySQL had the potential to cause them a lot of problems. Oracle found a way to stop that. If it was a predatory move against MySQL AB, everything was perfect, including the timing. Many companies were just waiting for the 5.0 release to try it out I'm sure, and the next thing they know Oracle has MySQL AB by the ____. It's too coincidental, and too perfect, there's no way it's a "merger".
Oracle may have purchased MySQL to prevent them from lowering the expected price of database software. If managers start to hear about MySQL costing $495 (or whatever), then they may expect a generally lower price for Oracle.
Also, the type of database practices common among MySQL users, like pushing work into the application, aren't on a trajectory toward Oracle.
Somehow I doubt you'll give up this argument, because you've clearly already classified me, regardless of fact.
As long as we're making baseless characterizations, I imagine you make similar classes for people's political beliefs. To you, one statement can make someone either a "liberal" or a "neocon" and you instantly know every other belief that they hold.
A pg install on a good disk that crashes the server and/or corrupts the data is a major bug. Any information you have about that should be reported in detail to the pgsql-general list. If you can reproduce it, even better, and please report that to pgsql-general.
I am somewhat skeptical that you have encountered such a bug. It is more likely a problem with your disk write cache (many disks lie about having stored some given data permanently), or some other issue.
Can you please port more details? We should get to the bottom of this. What version are you using? What OS? What arch? Is write cache enabled on your disk? What leads up to a failure?
hint: you don't win converts by talking down to them.
Was I condescending in any way? I just posted the facts when someone clearly asked for them.
I think you should not use a database based on a bunch of slashdot posts made by two groups of people (1) People who don't use PostgreSQL but want to jump on the bandwagon, and in the process look stupid (2) MySQL users who want to make PostgreSQL people look bad.
Instead, try the mailing lists, which (for PostgreSQL) are refreshingly helpful and informative.
I recommend not dismissing table-level trigger-based replication. But if it doesn't work for your application, I guess you'll have to look elsewhere. PostgreSQL isn't for every possible situation. Just don't dismiss Slony because of a little configuration, it's actually a good product.
It's interesting how many times people, like MySQL users, can convince themselves that nothing can hurt their product. They have wrapped themselves completely around a company with $20M in VC, and they assumed it was stable enough. Some people said that they shouldn't depend on a single small company, but that was mere theory. Now it's reality.
Even if nothing bad happens, and they find a way to work it all out, this should awaken the MySQL users to the fact that they are vulnerable. Realistically, it would be a long time before the GPL version was successfully managed by independent developers. That needs to change. The MySQL community needs to be the base upon which MySQL AB runs their business, not the other way around.
PostgreSQL is a great example. Great Bridge, LLC, started a business around PostgreSQL and at that time they were the main source of development money for PostgreSQL (or at least a main source). However, everyone agreed to not let PostgreSQL depend on Great Bridge. It turns out the VCs got cold feet and backed out (most likely scared because of the downturn). PostgreSQL still had a thriving community to continue development, so little time was lost, and the product has been gaining in leaps and bounds ever since. The people hired away by Great Bridge were quickly rehired by other companies. Now there are many companies that support PostgreSQL, like Command Prompt, Fujitsu, Afilias, Software Research Associates (SRA), Aglio DB, and Red Hat to name just a few (I'm sure I left some out).
If the same thing happens to MySQL AB that happened to Great Bridge, there would be little other than shattered remains of a community. There would be GPL code and no infrastructure or community to develop it.
How many app developers look at the DBMS source on a regular basis anyway? If it works, they'd never need to.
I was referring to the difficulty of MySQL using SAP DB as a replacement storage engine. For that, MySQL developers would certainly need to look at the source.
I don't know the truth, but I'll state something as fact in hopes that nobody catches me.
Actually, it was more along the lines of: "I don't know the truth, here's what I heard, comment if I'm wrong."
I have seen PostgreSQL's source code, and it's very nice. I haven't seen the source code for MySQL or SAP DB. I stated that clearly and did not mislead anyone.
SAP DB is very, very different from MySQL. They can't just bolt it in and have working transactions. I haven't seen the source code for either, but I've heard that MySQL's source code is a real mess, and that SAP DB's source code is a real mess in comparison to MySQL's source code.
I heard that SAP DB is built for mainframes, and that all the variables are cryptic, abbreviated german, and that it uses a customized build system that is really hacked together. Good luck finding programmers to work on that.
I can only assume you grossly misused PostgreSQL or some other software on the machine. PostgreSQL has a legendary reputation for reliability and stability, which has held up perfectly for me for years (no postgresql failures ever).
And if a disk crashes, you can hardly blame PostgreSQL. PostgreSQL has several great online backup systems available: Slony-I (repliaction), point-in-time recovery (PITR), and pg_dump. Use them.
You are also the first person I've heard describe PostgreSQL as a "memory hog".
My guess is that you made no attempt to diagnose the problem. I doubt your problems are related to a PostgreSQL bug. You could have reported your problems on pgsql-general, and I'm sure people there would have helped you as long as you provided good information.
PostgreSQL. A short list of benefits: - MVCC reduces need for locking, often called "better than row-level locking" - Also has row level locking - ACID compliant - transactions, and savepoints (which are SQL nested transactions) - point in time recovery (PITR) allows "time-travel" and parallel timelines. It's a little much to explain here, but if you encounter a problem and notice it a week later, you can go back in time, prevent the problem, and replay everything else that happened that week. All the good and none of the bad from a sci-fi book:) - VERY extensible: you can make user-defined functions in any of PL/pgSQL, PL/perl, PL/python, PL/java, C, or SQL. And if that's not enough, you can write another procedural language to support your favorite language. - You can make a user-defined aggregate function using any of those languages. - User-defined types - triggers - views - subselects - query rewriting rules (which can be used to make any view updatable/insertable) - constraints - good, well-maintained, and BSD licensed replication software available.
New in 8.1 (which is beta now): - Two-phase commit (2PC) - IN/OUT/INOUT parameters to functions - rudimentary table partitioning - bitmap index scans - autovacuum intelligently automates a long standing maintenence procedure, making the database easier to administer. - SQL ROLES - more options for row-level locking
Slashdot Mirror
Note that I said "shareholders" and not "stockholders". MySQL is private, but they got something like $20M in VC not too long ago. If you give charity to MySQL AB, you're just lining the pockets of the VCs, who aren't in it for the spirit of the GPL. I recommend the FSF or some other organized group that can effectively develop software -- and give you a tax break. Here are some of the places I have given money:
- FreeBSD: Interestingly, I gave them money before I even really used FreeBSD, because at the time, they needed small donations. Now I use it in production and I love it!
- PostgreSQL
- FreeNet: I regret donating money to FreeNet. I sent them like $10. My intention at the time was to promote free speech on the internet. When I figured out that it's really nothing but horrible filth, I decided that I didn't want them using anything of mine to support that kind of content. The internet is free enough, hopefully.
- LinuxFund: I actually just use a mastercard, and it builds up money in the linuxfund account. I think they're still looking for a good place to spend it, so I would say they're not very organized. But I suppose they'll probably end up just kicking it off to the FSF or something, so it should work out.
Next time I make a donation, it will probably be to FreeBSD, FSF, OpenBSD (gotta love openssh), or PostgreSQL.
By the way, usually increasing your eating frequency is good for losing weight and gaining muscle (not to mention general health & feeling good). I suppose whatever works for you. I don't gain muscle easily either.
I agree with you in general, but your example is just not working for me. Typically, you would use a "float" datatype for an extremely large year, not a timestamp/date. MySQL has a float datatype.
But in general, I agree that type extensibility is a vital component of an RDBMS.
That would mean "death cycle" for MySQL DB. Nobody would base any new installations on MySQL if that happened. PostgreSQL has it's own SQL parser.
Yes, that's what I meant of course.
However, because of Oracle's hostile move, I tend to think of it as though Oracle bought MySQL AB itself. It's not exactly the same, but it certainly could turn out that way.
In PostgreSQL, I get:
=> select '1000000-10-10 10:10:10'::timestamp;
ERROR: timestamp out of range: "1000000-10-10 10:10:10"
I'm a big PostgreSQL fan, but you're just being rediculous if you ask MySQL to accept arbitrarily large years. It should error out and be done.
How many scientific applications require you to know what day of the week Oct 18, 20000000000000005 is?
I think you're looking for the "float" datatype. And if you're not, you really should make your own type, because your needs are obviously very specific.
that they would at least ask for help
They are a commercial company. It only makes sense for people to donate to the cause itself, that is, the actual development of the MySQL DB product; not the shareholders behind a company that is associated with the cause. How would you feel if you donated some money, and then the investors liquidated or changed the business model? Your charity just went to some suits.
I am willing to skip a meal
It isn't a hunger strike, dude. At least make enough use of the bounties of modern society to eat 3 meals per day!
Yes, that's the difficulty.
MySQL can only go through so many "rebirths" (MyISAM, BDB, InnoDB, ____ ) before the users figure out that the only thing that's really "MySQL" is the language.
And people don't make new database installations based on syntax.
Now, MySQL doesn't really compete with Oracle *yet.*
Indirectly, they do. You could look at it like Oracle is nipping it in the bud, I suppose.
Oracle certainly doesn't want a company running around to a bunch of people saying "Database" and "$495" in the same sentence.
And they certainly don't want a lot of casual database users who shift the market away from Oracle's traditional database model of "data integrity, expensive DBAs, referential integrity, expensive DBAs, redundancy, and expensive DBAs", to MySQL's model of "throw your data here, and when you ask for it, we'll send it back to you".
The GPL branch of the code, however, would be able to continue essentially unchanged
By who? Not by MySQL AB. It takes a long time to make a new community work effectively.
MySQL AB is between a rock and a hard place, I think we can agree here. If Oracle cuts off InnoDB from commercial licensing, MySQL will stop developing/supporting it, it's only a matter of time. They simply can't have a GPL version that's better than their commercial version. Then, without transactions or RI, their "enterprise-ness" and usefulness will be called into question.
So that leaves the community. But the community is too wrapped around MySQL AB to function on it's own just yet. That will take time.
And that time is precisely what Oracle doesn't want MySQL to have. If the development of MySQL DB is set back by 12-18 months, that will surely be a victory for Oracle, who will secure a strong lead ahead of the most popular open source database. The wind will be stolen from the 5.0 release, and another few rounds of businessmen will make long-term commitments to Oracle (in the form of licenses and hardware).
What is the downside to Oracle?
The Innobase purchase/ MySQL debacle is really an indictment of their business and development model.
.org and .info), Software Research Associates (SRA), Red Hat, Aglio DB, EnterpriseDB (won LinuxWorld "Best Database Solution" last year, beating Oracle), Command Prompt (I probably left a lot out).
MySQL AB is at the epicenter of development of MySQL DB, and requires copyright transfers for any outside changes. Paid developers at one small company largely create and support the entire database. Some users get a sense of security that there is "one person to go to", and a single focused business behind it. In some ways this business model worked well... their marketing was very successful, and the database might be described as more "unified" than, for example, PostgreSQL, where things like FTS and replication are independently developed (which is actually good, but can confuse users who think that "it's not good enough to be included").
However, the PostgreSQL development model has been working very effectively, not dependent on any one company. A short list of contributors includes the likes of Fujitsu, Sun, Affilias (manages all
When Great Bridge hired a bunch of the PostgreSQL developers, then got scared and pulled funding, the developers went back to the community. The community was the core to begin with, and development continued as always. Other companies came in to support it, and development has never been stronger. More importantly, the community has never been stronger.
The reason MySQL DB users are concerned, even though the source is GPL, is because MySQL DB is heavily dependent on MySQL AB. If MySQL is forced out by Oracle, what's left aside from some source code? There are a lot of users who would rally and try to build a community. But building a community to support an RDBMS takes more than just a few good programmers. It takes years to build the kind of community that works like the PostgreSQL Global Development Group (PGDG). It takes programmers, organizers, advocates, managers, advocates, support channels, channels for accepting new developers (for instance, if a company wants to pay for a feature), decision makers, and arbitrators (to prevent too much forking). And it takes a lot of time to figure out who does what, and when they do it, and how to reconcile conflicts or scheduling difficulties, how to work as a team so that work is integrated properly and time is not wasted.
If someone has a proposal for a feature, who do they ask so that it's heard? Will a reliable decision be made about whether/when to progress? Who should step up and program? Who will open the channels of communication between the programmer and any other programmers working in similar code areas? Who will enforce project "standards"? Who will devise the standards? Does it go in this release or wait 'til the next? When is feature freeze? Who determines what quality level constitutes a release? Should the patch be backported? If it breaks any compatibility, who will devise a proper release timeline to avoid hurting existing users too much?
It really takes a long time to build those conventions and organize people into a functional development group. MySQL DB users can only hope that MySQL AB is still around for a while. If MySQL AB goes the way of Great Bridge, MySQL DB may be left in chaos. In the meantime, start forming a community that can operate outside of MySQL AB. The monolithic development/business model seems to be in question right now.
they could elect to kill InnoDB at some future point. I just don't see how this is a win for FOSS. To me, this isn't a likely danger, though.
I think it's very likely that Oracle does just that. Oracle wins on several fronts:
(1) Set back a competitor by a lot, possibly completely knocking it out of some markets.
(2) Cause more OSS FUD: "What will happen to your open source vendor? It could evaporate tomorrow. Stick with Oracle, who will be there for you."
(3) Shift the market back toward the mentality of traditional relational databases, where there is a lot of emphasis on data integrity constraints, and expensive DBAs, and less emphasis on casual users.
MySQL had the potential to cause them a lot of problems. Oracle found a way to stop that. If it was a predatory move against MySQL AB, everything was perfect, including the timing. Many companies were just waiting for the 5.0 release to try it out I'm sure, and the next thing they know Oracle has MySQL AB by the ____. It's too coincidental, and too perfect, there's no way it's a "merger".
Oracle may have purchased MySQL to prevent them from lowering the expected price of database software. If managers start to hear about MySQL costing $495 (or whatever), then they may expect a generally lower price for Oracle.
Also, the type of database practices common among MySQL users, like pushing work into the application, aren't on a trajectory toward Oracle.
Somehow I doubt you'll give up this argument, because you've clearly already classified me, regardless of fact.
As long as we're making baseless characterizations, I imagine you make similar classes for people's political beliefs. To you, one statement can make someone either a "liberal" or a "neocon" and you instantly know every other belief that they hold.
A pg install on a good disk that crashes the server and/or corrupts the data is a major bug. Any information you have about that should be reported in detail to the pgsql-general list. If you can reproduce it, even better, and please report that to pgsql-general.
I am somewhat skeptical that you have encountered such a bug. It is more likely a problem with your disk write cache (many disks lie about having stored some given data permanently), or some other issue.
Can you please port more details? We should get to the bottom of this. What version are you using? What OS? What arch? Is write cache enabled on your disk? What leads up to a failure?
so why doesnt anyone use it?
Lots of people do.
hint: you don't win converts by talking down to them.
Was I condescending in any way? I just posted the facts when someone clearly asked for them.
I think you should not use a database based on a bunch of slashdot posts made by two groups of people
(1) People who don't use PostgreSQL but want to jump on the bandwagon, and in the process look stupid
(2) MySQL users who want to make PostgreSQL people look bad.
Instead, try the mailing lists, which (for PostgreSQL) are refreshingly helpful and informative.
Slony. I've tried it and it works great.
I recommend not dismissing table-level trigger-based replication. But if it doesn't work for your application, I guess you'll have to look elsewhere. PostgreSQL isn't for every possible situation. Just don't dismiss Slony because of a little configuration, it's actually a good product.
It's interesting how many times people, like MySQL users, can convince themselves that nothing can hurt their product. They have wrapped themselves completely around a company with $20M in VC, and they assumed it was stable enough. Some people said that they shouldn't depend on a single small company, but that was mere theory. Now it's reality.
Even if nothing bad happens, and they find a way to work it all out, this should awaken the MySQL users to the fact that they are vulnerable. Realistically, it would be a long time before the GPL version was successfully managed by independent developers. That needs to change. The MySQL community needs to be the base upon which MySQL AB runs their business, not the other way around.
PostgreSQL is a great example. Great Bridge, LLC, started a business around PostgreSQL and at that time they were the main source of development money for PostgreSQL (or at least a main source). However, everyone agreed to not let PostgreSQL depend on Great Bridge. It turns out the VCs got cold feet and backed out (most likely scared because of the downturn). PostgreSQL still had a thriving community to continue development, so little time was lost, and the product has been gaining in leaps and bounds ever since. The people hired away by Great Bridge were quickly rehired by other companies. Now there are many companies that support PostgreSQL, like Command Prompt, Fujitsu, Afilias, Software Research Associates (SRA), Aglio DB, and Red Hat to name just a few (I'm sure I left some out).
If the same thing happens to MySQL AB that happened to Great Bridge, there would be little other than shattered remains of a community. There would be GPL code and no infrastructure or community to develop it.
How many app developers look at the DBMS source on a regular basis anyway? If it works, they'd never need to.
I was referring to the difficulty of MySQL using SAP DB as a replacement storage engine. For that, MySQL developers would certainly need to look at the source.
Of course, these announcements cast a long shadow over the upcoming 5.0 release.
Especially when MySQL AB is silent on the issue. We can only assume they have nothing reassuring to say.
I don't know the truth, but I'll state something as fact in hopes that nobody catches me.
Actually, it was more along the lines of: "I don't know the truth, here's what I heard, comment if I'm wrong."
I have seen PostgreSQL's source code, and it's very nice. I haven't seen the source code for MySQL or SAP DB. I stated that clearly and did not mislead anyone.
A brighter LAMP: Linux Apache Middleware PostgreSQL
SAP DB is very, very different from MySQL. They can't just bolt it in and have working transactions. I haven't seen the source code for either, but I've heard that MySQL's source code is a real mess, and that SAP DB's source code is a real mess in comparison to MySQL's source code.
I heard that SAP DB is built for mainframes, and that all the variables are cryptic, abbreviated german, and that it uses a customized build system that is really hacked together. Good luck finding programmers to work on that.
I can only assume you grossly misused PostgreSQL or some other software on the machine. PostgreSQL has a legendary reputation for reliability and stability, which has held up perfectly for me for years (no postgresql failures ever).
And if a disk crashes, you can hardly blame PostgreSQL. PostgreSQL has several great online backup systems available: Slony-I (repliaction), point-in-time recovery (PITR), and pg_dump. Use them.
You are also the first person I've heard describe PostgreSQL as a "memory hog".
My guess is that you made no attempt to diagnose the problem. I doubt your problems are related to a PostgreSQL bug. You could have reported your problems on pgsql-general, and I'm sure people there would have helped you as long as you provided good information.
A minor nitpick, but it's "PostgreSQL", or "postgres" for short. It's never "Postgre".
PostgreSQL. A short list of benefits: :)
- MVCC reduces need for locking, often called "better than row-level locking"
- Also has row level locking
- ACID compliant
- transactions, and savepoints (which are SQL nested transactions)
- point in time recovery (PITR) allows "time-travel" and parallel timelines. It's a little much to explain here, but if you encounter a problem and notice it a week later, you can go back in time, prevent the problem, and replay everything else that happened that week. All the good and none of the bad from a sci-fi book
- VERY extensible: you can make user-defined functions in any of PL/pgSQL, PL/perl, PL/python, PL/java, C, or SQL. And if that's not enough, you can write another procedural language to support your favorite language.
- You can make a user-defined aggregate function using any of those languages.
- User-defined types
- triggers
- views
- subselects
- query rewriting rules (which can be used to make any view updatable/insertable)
- constraints
- good, well-maintained, and BSD licensed replication software available.
New in 8.1 (which is beta now):
- Two-phase commit (2PC)
- IN/OUT/INOUT parameters to functions
- rudimentary table partitioning
- bitmap index scans
- autovacuum intelligently automates a long standing maintenence procedure, making the database easier to administer.
- SQL ROLES
- more options for row-level locking