Humor me: Postgresql vs. MySql (esp. licensing)
John Wells
the flamethrowers.
I'm preparing to enter a discussion with management at my company
regarding going forward as either a MySql shop or a Postgresql shop.
It's my opinion that we should be using PG, because of the full ACID
support, and the license involved. A consultant my company hired before
bringing me in is pushing hard for MySql, citing speed and community
support, as well as ACID support.
My biggest concern with MySQL is licensing. We need to keep costs low,
and last I remember the parent company was being pretty strict on "fair
use" under the GPL. If I recall, they even said a company would have to
license the commercial version if it were simply used operationally within
the company.
Also, I was under the impression that Postgresql had pretty much caught up
with MySql in the speed category...is this not the case?
Finally, ACID support in mysql always seemed kind of a hack....perhaps
this has changed?
Thanks for any input (armament ;) ) you can provide.
John
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majo...@postgresql.org so that your
message can get through to the mailing list cleanly
Richard Welty
> It's my opinion that we should be using PG, because of the full ACID
> support, and the license involved. A consultant my company hired before
> bringing me in is pushing hard for MySql, citing speed and community
> support, as well as ACID support.
you should also cite conformity to standards. MySQL is significantly
different from SQL standards in a number of regards. not that any are fully
conformant, but there are spots where MySQL is seriously "out there".
richard
--
Richard Welty rwe...@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
Oliver Elphick
> Yes, I know you've seen the above subject before, so please be gentle with
> the flamethrowers.
>
> I'm preparing to enter a discussion with management at my company
> regarding going forward as either a MySql shop or a Postgresql shop.
>
> It's my opinion that we should be using PG, because of the full ACID
> support, and the license involved. A consultant my company hired before
> bringing me in is pushing hard for MySql, citing speed and community
> support, as well as ACID support.
Speed depends on the nature of use and the complexity of queries. If
you are doing updates of related tables, ACID is of vital importance and
MySQL doesn't provide it.
> My biggest concern with MySQL is licensing. We need to keep costs low,
> and last I remember the parent company was being pretty strict on "fair
> use" under the GPL. If I recall, they even said a company would have to
> license the commercial version if it were simply used operationally within
> the company.
Unless they actually attach extra conditions to the GPL (i.e. "This
product is licensed under GPL with the following extra conditions...")
this is rubbish. The GPL allows you to do what you like with the
software internally; its restrictions only apply to further
distribution. MySQL would _like_ you to pay for support or buy a
commercial licence, but you only _need_ to buy a licence if you want to
distribute a modified or linked MySQL without distributing your own
source code.
If that position changes, we (Debian) will need to move MySQL from
Debian's main archive to its non-free section, or even drop it
altogether. So do let me know if that becomes necessary!
> Also, I was under the impression that Postgresql had pretty much caught up
> with MySql in the speed category...is this not the case?
MySQL is very good for simple queries by not too many users at a time.
Otherwise it's no better than PostgreSQL and often worse to unusable,
according to other posts I've seen.
> Finally, ACID support in mysql always seemed kind of a hack....perhaps
> this has changed?
Not that I know of.
> Thanks for any input (armament ;) ) you can provide.
I took over maintenance of a project written in MySQL. It is a total
nightmare. No triggers, foreign keys or constraints, and bizarre
timestamp handling. Given the choice, I wouldn't touch it with a ten
foot pole.
--
Oliver Elphick Oliver....@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Let no man say when he is tempted, I am tempted of
God; for God cannot be tempted with evil, neither
tempteth he any man; But every man is tempted, when he
is drawn away of his own lust, and enticed."
James 1:13,14
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Shridhar Daithankar
> On Wed, 8 Oct 2003 11:28:00 -0400 (EDT) John Wells <j...@sourceillustrated.com> wrote:
>
>
>>It's my opinion that we should be using PG, because of the full ACID
>>support, and the license involved. A consultant my company hired before
>>bringing me in is pushing hard for MySql, citing speed and community
>>support, as well as ACID support.
>
>
> you should also cite conformity to standards. MySQL is significantly
> different from SQL standards in a number of regards. not that any are fully
> conformant, but there are spots where MySQL is seriously "out there".
Yeah.. like inserting a biiig number in integer field in a transaction without
error and not getting it back after commit.. or accepting '00-00-00 00:00:00' as
a valid datetime stamp.. something like that..
How much deviation is that from ACID? 180 degrees...:-)
One of my friend lost data with mysql yesterday.. The machine was taken down for
disk upgrade and mysql apperantly did not commit the last insert.. OK he was
using myisam but still..:-)
Shridhar
Unihost Web Hosting
I've been thinking about this for sometime, since a couple of my
associates are looking to build a commercial app based around JDBC. The
difficulty came when we looked at redistributing a MySQL JDBC driver
.jar with the application. From what I can tell, since you distribute
the JDBC driver they assume that somewhere it's going to be used with a
MySQL server and therefore requires licensing. It wasn't exactly clear
IMHO or straightforward. So they've decided to go with PG only for the
time being, which makes running the server on Windows a little more
difficult, but who wants to run windows anyway!
As far as speed goes, I think that there isn't enough in it anymore to
comment about. Sure MySQL is faster in XYZ scenario, but PG is faster
in ABC scenario, swings and roundabouts. IMHO the only place where
MySQL has a clear advantage is the fact that it replicates right out of
the box, with very little difficulty (see my earlier post today) and is
quite robust.
Just my 2 Cents
Cheers
T.
John Wells wrote:
John Wells
> Unless they actually attach extra conditions to the GPL (i.e. "This
> product is licensed under GPL with the following extra conditions...")
> this is rubbish. The GPL allows you to do what you like with the
> software internally; its restrictions only apply to further
> distribution. MySQL would _like_ you to pay for support or buy a
> commercial licence, but you only _need_ to buy a licence if you want to
> distribute a modified or linked MySQL without distributing your own
> source code.
>
> If that position changes, we (Debian) will need to move MySQL from
> Debian's main archive to its non-free section, or even drop it
> altogether. So do let me know if that becomes necessary!
Then read this page: http://www.mysql.com/products/licensing.html
Very carefully. Particularly the sentence "As long as you never
distribute (internally or externally)"...
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
John Wells
the flamethrowers.
I'm preparing to enter a discussion with management at my company
regarding going forward as either a MySql shop or a Postgresql shop.
It's my opinion that we should be using PG, because of the full ACID
support, and the license involved. A consultant my company hired before
bringing me in is pushing hard for MySql, citing speed and community
support, as well as ACID support.
My biggest concern with MySQL is licensing. We need to keep costs low,
and last I remember the parent company was being pretty strict on "fair
use" under the GPL. If I recall, they even said a company would have to
license the commercial version if it were simply used operationally within
the company.
Also, I was under the impression that Postgresql had pretty much caught up
with MySql in the speed category...is this not the case?
Finally, ACID support in mysql always seemed kind of a hack....perhaps
this has changed?
Thanks for any input (armament ;) ) you can provide.
John
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Randal L. Schwartz
Shridhar> Yeah.. like inserting a biiig number in integer field in a transaction
Shridhar> without error and not getting it back after commit.. or accepting
Shridhar> '00-00-00 00:00:00' as a valid datetime stamp.. something like that..
Shridhar> How much deviation is that from ACID? 180 degrees...:-)
Unverified, but you can apparently try to store a huge number into a
short integer, and MySQL silently truncates to maxint. No error. No
warning.
No place for it in a real business environment. :(
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
scott.marlowe
> Yes, I know you've seen the above subject before, so please be gentle with
> the flamethrowers.
>
> I'm preparing to enter a discussion with management at my company
> regarding going forward as either a MySql shop or a Postgresql shop.
>
> It's my opinion that we should be using PG, because of the full ACID
> support, and the license involved. A consultant my company hired before
> bringing me in is pushing hard for MySql, citing speed and community
> support, as well as ACID support.
MySQL almost has acid support, but their failure to support data type
constraints (i.e. insert the number 8 billion in an int4 and get the
number 2^30 back when you select it, with NO WARNING of an overflow.)
Postgresql actually has a far more active community, they just don't have
as large of a marketing wing as MySQL. Keep in mind, community means the
people using it answering questions on lists to me, not seeing a new press
release every three weeks telling us how some new feature has been added.
Postgresql has community in spades, and that community is mostly people
who do things like run the .org and .info domains, not the folks who run
large text based discussion sites like slashdot.
Everytime you do to slashdot, you use one database to get there (.org is
resolved by postgresql databases) and another to display contents (mysql
runs their backend.)
When was the last time you typed in a .org domain and didn't get a
response for a site you knew existed? On the other hand, when was the
last time you went to Slashdot or Kuro5hin and got a static screen with
the login box showing because the database was down again?
Your consultant sounds like a cheer leader. I like cheer leaders, when
they have pom poms and are doing the splits, but they have no place in
deciding which technology to use.
I've recently been testing Postgresql on our new boxes for surviving
having the plug pulled in the middle of 200 simultaneous transactions. On
our old PIII-750x2 machine with SCSI drives, the database comes right back
up, no corruption. You should demand to test both MySQL and Postgresql
under those circumstances and see how each does.
Speed is a seconday concern for a database, reliability comes first, and
Postgresql has that in spades.
> My biggest concern with MySQL is licensing. We need to keep costs low,
> and last I remember the parent company was being pretty strict on "fair
> use" under the GPL. If I recall, they even said a company would have to
> license the commercial version if it were simply used operationally within
> the company.
Licensing isn't as big a deal as some would think, after all, a commercial
MySQL license if chump change compared to the support contract on a Sun
E10K or a good network switch.
Yes, I still prefer the more pure Postgresql BSD license, but it's not a
sticking point for me.
> Also, I was under the impression that Postgresql had pretty much caught up
> with MySql in the speed category...is this not the case?
Caught up? It's been much faster for a while on many things. for
instance, how long does it take for MySQL to return a dataset from a view?
Well, since that feature's not implemented, Postgresql is much faster at
that. how long does it take MySQL to fire a trigger? It doesn't have
them, so Postgresql wins there. It's like comparing a space station to a
lawn mower.
In general, MySQL is a bit faster at ultra simple queries, while
Postgresql is quite a bit faster at complex queries. The more complexity
you throw at the database, the better postgresql handles it. MySQL's lack
of features and tendency to fail silently when it should complain loudly
makes it suitable for content management, but not for transactional work
like financials / payroll / forecasting / cost benefit analyses, etc...
> Finally, ACID support in mysql always seemed kind of a hack....perhaps
> this has changed?
Not really. Firstly, you have to use innodb tables, and if you forget, it
silently forgets to remind you that you've chosen the wrong data type.
Secondly, it doesn't support any form of constraints other than
fk/pk/unique. and it doesn't support data type constraints as mentioned
above.
> Thanks for any input (armament ;) ) you can provide.
Sure, you might wanna trawl the general and advocacy archives for more
discussions in the last year or so.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majo...@postgresql.org)
Oliver Elphick
> Oliver Elphick said:
> > If that position changes, we (Debian) will need to move MySQL from
> > Debian's main archive to its non-free section, or even drop it
> > altogether. So do let me know if that becomes necessary!
>
> Then read this page: http://www.mysql.com/products/licensing.html
>
> Very carefully. Particularly the sentence "As long as you never
> distribute (internally or externally)"...
But as far as Debian is concerned, paragraph 1 applies:
1. Free use for those who are 100% GPL
If your application is licensed under GPL or compatible OSI license
approved by MySQL AB, you are free and welcome to ship any GPL software
of MySQL AB with your application. By "application" we mean any type of
software application, system, tool or utility. For doing this, you do
not need a separate signed agreement with MySQL AB, because the GPL text
is sufficient...
That makes it free under the Debian Free Software Guidelines, so I have
no grounds for requesting its removal. :-(
--
Oliver Elphick Oliver....@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Let no man say when he is tempted, I am tempted of
God; for God cannot be tempted with evil, neither
tempteth he any man; But every man is tempted, when he
is drawn away of his own lust, and enticed."
James 1:13,14
---------------------------(end of broadcast)---------------------------
Christopher Browne
> It's my opinion that we should be using PG, because of the full ACID
> support, and the license involved. A consultant my company hired
> before bringing me in is pushing hard for MySql, citing speed and
> community support, as well as ACID support.
You should ask that consultant what he anticipates the licensing fees
will be, and why. It seems improbable that would be cheap.
But don't bother using us as the source of questions; head to the
"horse's mouth."
<http://www.mysql.com/products/licensing.html>
And compare to...
<http://www.postgresql.org/licence.html>
> My biggest concern with MySQL is licensing. We need to keep costs
> low, and last I remember the parent company was being pretty strict
> on "fair use" under the GPL. If I recall, they even said a company
> would have to license the commercial version if it were simply used
> operationally within the company.
To put it in their words...
"Our guiding principle is to have all our source code open, and to
offer it free of payment (i.e. gratis) to those who commit to
doing the same. We have concluded that the GPL licence best
fulfills this principle, and that's why we use the GPL.
Therefore the answer to (a questioner's) question is: "Your PHP
app that works with MySQL, if distributed, will either have to be
GPL (or another OSI-approved and MySQL-approved open source
licence) or you will need a commercial licence of MySQL."
Sometimes people say "But I cannot open source my application!"
and they may have valid reasons for this. Our response is then:
"If you have a valid reason not to be open source, wouldn't that
same reasoning apply to us?."
This goes to the core of MySQL AB's business idea of Quid pro Quo
- if you are open source, we are open source - if you are closed
source, we are commercial."
When someone proposed building an LGPLed interface to MaxDB (what they
call their acquisition of SAP-DB), the comments were also quite
illuminating:
<http://marc.theaimsgroup.com/?l=sapdb-general&m=106045880005921&w=2>
--
select 'aa454' || '@' || 'freenet.carleton.ca';
http://www3.sympatico.ca/cbbrowne/languages.html
I am not a number!
I am a free man!
John Wells
originally posted from a non-subscribed address), but perhaps he missed
it.
John
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
Jonathan Bartlett
> > support, and the license involved. A consultant my company hired before
> > bringing me in is pushing hard for MySql, citing speed and community
> > support, as well as ACID support.
>
The fact is that PG has features that MySQL doesn't have that are REALLY
needed. The big ones being views, subselects, functions, triggers, and
constraints. Small queries run by a few users may run faster on MySQL.
When you get to real queries by large groups, it almost always favors PG.
In fact, as youre application grows, you will find MySQL completely
useless. I always get frustrated when MySQL is touted as a great
open-source database. Especially when the field is very rich - PG, SAP,
and Firebird all come to mind.
Jon
Oliver Elphick
> The mysql license restricts the distribution of mysql if the aggregate
> distribution contains non-GPL software. DFSG #1 does not allow for a
> distinction between free and non-free software among the "components of
> an aggregate system". Neither does the GPL make such distinctions.
>
> The "Commercial use for everyone else" term is either (1) completely
> incompatible with the GPL, or (2) completely circumventable, since if I
> received MySQL sources under the GPL, under section 2.b. of the GPL I
> have the obligation to use GPL (with no MySQL AB additions) for any
> third party I distribute to, for any purpose. So I put my noncommercial
> GPL sources for MySQL on my noncommercial FTP server, and anyone can
> download and use them for any purpose, commercial or not, solely under
> the terms of the GPL, because the GPL is how I got the source from MySQL
> AB.
You do misunderstand this, I'm afraid. The MySQL user has a choice of 2
mutually exclusive licences if he is going to distribute: either GPL,
which means opening his own code, or commercial. MySQL's option 2 (free
for internal use) is meaningless and unenforceable (what on earth is
internal distribution as opposed to use?), but not relevant to Debian
which only cares if the software is DFSG-compliant. Option 1 (GPL) is
available and makes it DFSG-free, so the other licence options don't
need to be examined.
Debian's copy of MySQL is therefore distributed under GPL. I don't
think we do reproduce the other licence options. Any copy obtained from
Debian is therefore automatically GPL. To get a commercial copy, you
would, strictly, have to go back to MySQL's site.
--
Oliver Elphick Oliver....@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Let no man say when he is tempted, I am tempted of
God; for God cannot be tempted with evil, neither
tempteth he any man; But every man is tempted, when he
is drawn away of his own lust, and enticed."
James 1:13,14
---------------------------(end of broadcast)---------------------------
Al Hulaton
> regarding going forward as either a MySql shop or a Postgresql shop.
- PostgreSQL supports constraints. MySQL doesn't; programmers need to
take care of that from the client side
- Define a 32-bit field in MySQL. Insert a 64-bit number instead. Common
sense tells you the value would be rejected. Yet MySQL happily folds it
in and carries on its merry way.
- Triggers: PostgreSQL yes, MySQL no. Translates into more work for your
MySQL developers in both creating your app and moving it forward with
each rev.
- Transactions: We've been here before. Suffice to say, MySQL+InnoDB is
almost there. Plain ol' MySQL doesn't have it, which tells you something
about their philosophy towards database design.
- Speed: mHz for mHz, MySQL has PostgreSQL beat for simple searches.
Once you start getting complex, PostgreSQL is competitive. I think this
speed issue is overrated: over time, PostgreSQL has sped up and MySQL
has slowed down which is pretty impressive, considering both have added
features from their early versions.
- Scalability: MySQL dies before PostgreSQL does. PostgreSQL under
extreme load may slow down, but it'll finish. MySQL simply gives up.
If the project is for slapping dynamic html on a page with data not
crucial for business, MySQL is probably fine. But if we're talking
business processes, data you care dearly about, MySQL is out. Lack of
constraints is the deal-breaker for me.
PostgreSQL is more comparable to Oracle. MySQL is more like Access --
quick and dirty.
But boy, they sure are good at marketing. Probably because MySQL is
developed by a single company with venture cap and a public relations
company whereas PostgreSQL is developed out in the open by a close-knit
community.
--
Best,
Al Hulaton | Sr. Account Engineer | Command Prompt, Inc.
503.222.2783 | ahul...@commandprompt.com
Home of Mammoth PostgreSQL and 'Practical PostgreSQL'
Managed PostgreSQL, Linux services and consulting
Read and Search O'Reilly's 'Practical PostgreSQL' at
http://www.commandprompt.com
Vivek Khera
OE> But as far as Debian is concerned, paragraph 1 applies:
OE> 1. Free use for those who are 100% GPL
[[ ... ]]
OE> That makes it free under the Debian Free Software Guidelines, so I have
OE> no grounds for requesting its removal. :-(
So if I build and sell an appliance (hardware+software) based on
debian and using the 'free' collection of software, suddenly I'm not
in compliance with their license. Sounds like a time-bomb waiting to
explode.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: kh...@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Alvaro Herrera
> 1. Free use for those who are 100% GPL
>
> If your application is licensed under GPL or compatible OSI license
> approved by MySQL AB, you are free and welcome to ship any GPL software
> of MySQL AB with your application. By "application" we mean any type of
> software application, system, tool or utility. For doing this, you do
> not need a separate signed agreement with MySQL AB, because the GPL text
> is sufficient...
So, what is the list of "compatible OSI licenses approved by MySQL AB"?
Can they modify such a list?
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La experiencia nos dice que el hombre peló millones de veces las patatas,
pero era forzoso admitir la posibilidad de que en un caso entre millones,
las patatas pelarían al hombre" (Ijon Tichy)
Joshua D. Drake
Here is the simple thing about MySQL licensing. It is GPL. If you
modify the mySQL source or you link a proprietary app to mySQL without
a commercial license. You must distrubute your changes and or
application as GPL or GPL compatibile.
As far as speed is concerned: PostgreSQL is faster under
transactional/heavy loaded systems.
MySQL is very fast for "Hey, I need to get a web page up that has some
basic dynamic data"
MySQL is not ACID compliant, do not be fooled. The easiest argument is
this:
If you have a 32 bit integer column, and you try to insert a 64 bit
number... logical thought would suggest that the database should
throw an exception (which is a requirement of the 'C' in ACID) or fail
in some way. MySQL will not fail, instead it will insert a truncated
value of the 64 bit number and thus screw all of your data in the future.
There are others which I am sure MANY people can point out.
Sincerely,
Joshua Drake
John Wells wrote:
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - j...@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
Oliver Elphick
> >>>>> "OE" == Oliver Elphick <ol...@lfix.co.uk> writes:
>
> OE> But as far as Debian is concerned, paragraph 1 applies:
>
> OE> 1. Free use for those who are 100% GPL
>
> [[ ... ]]
>
> OE> That makes it free under the Debian Free Software Guidelines, so I have
> OE> no grounds for requesting its removal. :-(
>
> So if I build and sell an appliance (hardware+software) based on
> debian and using the 'free' collection of software, suddenly I'm not
> in compliance with their license. Sounds like a time-bomb waiting to
> explode.
It's licensed under the GPL, which means that you can indeed sell it, SO
LONG AS you make your own source code available to your customer under
the GPL or a compatible licence. Nothing in the GPL stops you demanding
money for the software; what it requires is that you make your source
code available. It's whole purpose is to force the freeing of source
code; it is not much concerned with money. For example, I remember
years ago installing a DG Aviion operating system upgrade, where I found
that the compiler was gcc, with the GPL prominently attached. And every
embedded-Linux device is in the same situation.
MySQL's licence does not require you to buy a licence for _any_
commercial use, but only for commercial use where you do not release
your source code under a GPL-compatible licence.
There seems to be an awful lot of confusion about the GPL. Maybe
Microsoft's campaign has been bearing fruit in unlikely quarters...
Bruce Momjian
> > So if I build and sell an appliance (hardware+software) based on
> > debian and using the 'free' collection of software, suddenly I'm not
> > in compliance with their license. Sounds like a time-bomb waiting to
> > explode.
>
> It's licensed under the GPL, which means that you can indeed sell it, SO
> LONG AS you make your own source code available to your customer under
> the GPL or a compatible licence. Nothing in the GPL stops you demanding
> money for the software; what it requires is that you make your source
> code available. It's whole purpose is to force the freeing of source
> code; it is not much concerned with money. For example, I remember
You also have to allow anyone who is given the source code the ability
to freely distribute it too. Meaning, you can't prevent one of your
customers from putting the code up on ftp and distributing it to anyone.
--
Bruce Momjian | http://candle.pha.pa.us
pg...@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Diogo Biazus
>Yes, I know you've seen the above subject before, so please be gentle with
>the flamethrowers.
>
>I'm preparing to enter a discussion with management at my company
>regarding going forward as either a MySql shop or a Postgresql shop.
>
>It's my opinion that we should be using PG, because of the full ACID
>support, and the license involved. A consultant my company hired before
>bringing me in is pushing hard for MySql, citing speed and community
>support, as well as ACID support.
>
>My biggest concern with MySQL is licensing. We need to keep costs low,
>and last I remember the parent company was being pretty strict on "fair
>use" under the GPL. If I recall, they even said a company would have to
>license the commercial version if it were simply used operationally within
>the company.
>
>Also, I was under the impression that Postgresql had pretty much caught up
>with MySql in the speed category...is this not the case?
>
>Finally, ACID support in mysql always seemed kind of a hack....perhaps
>this has changed?
>
>Thanks for any input (armament ;) ) you can provide.
>
>
Take a look at this document: http://sql-info.de/mysql/gotchas.html
You will find that there are some "features" that are realy undesirable
in a serious SGBD.
--
Diogo Biazus
di...@ikono.com.br
http://www.ikono.com.br
Dann Corbit
> From: Oliver Elphick [mailto:ol...@lfix.co.uk]
> Sent: Wednesday, October 08, 2003 3:10 PM
> To: Vivek Khera
> Cc: PostgreSQL general list
> Subject: Re: [GENERAL] Humor me: Postgresql vs. MySql (esp. licensing)
>
>
> On Wed, 2003-10-08 at 20:28, Vivek Khera wrote:
> > >>>>> "OE" == Oliver Elphick <ol...@lfix.co.uk> writes:
> >
> > OE> But as far as Debian is concerned, paragraph 1 applies:
> >
> > OE> 1. Free use for those who are 100% GPL
> >
> > [[ ... ]]
> >
> > OE> That makes it free under the Debian Free Software
> Guidelines, so I
> >
> > So if I build and sell an appliance (hardware+software) based on
> > debian and using the 'free' collection of software,
> suddenly I'm not
> > in compliance with their license. Sounds like a time-bomb
> waiting to
> > explode.
>
> It's licensed under the GPL, which means that you can indeed
> sell it, SO LONG AS you make your own source code available
> to your customer under the GPL or a compatible licence.
> Nothing in the GPL stops you demanding money for the
> software; what it requires is that you make your source code
> available.
Then who's going to pay for it?
> It's whole purpose is to force the freeing of
> source code; it is not much concerned with money. For
> example, I remember years ago installing a DG Aviion
> operating system upgrade, where I found that the compiler was
> gcc, with the GPL prominently attached. And every
> embedded-Linux device is in the same situation.
>
> MySQL's licence does not require you to buy a licence for
> _any_ commercial use, but only for commercial use where you
> do not release your source code under a GPL-compatible licence.
>
> There seems to be an awful lot of confusion about the GPL.
> Maybe Microsoft's campaign has been bearing fruit in unlikely
> quarters...
The reason that there is a lot of confusion is that the license
conditions are extremely confusing.
no...@celery.tssi.com
> disk upgrade and mysql apperantly did not commit the last insert.. OK he was
> using myisam but still..:-)
It sounds like that is more a problem with improper operating protocols
than with the underlying database.
Would PG know enough to do a commit regardless of how the database was
shut down? A second question is whether doing a commit is what the user
or application would always want to have happen, as it could result in a
half-completed transaction.
--
Mike Nolan
Alvaro Herrera
> Would PG know enough to do a commit regardless of how the database was
> shut down? A second question is whether doing a commit is what the user
> or application would always want to have happen, as it could result in a
> half-completed transaction.
If an open transaction is not explicitly committed and the client
disconnects, it is automatically rolled back.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Essentially, you're proposing Kevlar shoes as a solution for the problem
that you want to walk around carrying a loaded gun aimed at your foot.
(Tom Lane)
no...@celery.tssi.com
> disconnects, it is automatically rolled back.
So what would happen with MySQL? Does it leave the transaction
half-committed? The original implication was that data was lost, which
is what would happen with an uncommitted PG transaction as well.
--
Mike Nolan
---------------------------(end of broadcast)---------------------------
Alvaro Herrera
> > If an open transaction is not explicitly committed and the client
> > disconnects, it is automatically rolled back.
>
> So what would happen with MySQL? Does it leave the transaction
> half-committed? The original implication was that data was lost, which
> is what would happen with an uncommitted PG transaction as well.
It was not clear to me from the article that originally mentioned it
that it had an uncommitted transaction, though it may very well be the
case.
But given that ROLLBACK takes some unreasonable amount of time in MySQL,
what do you really expect? Did the rollback work when the poweroff was
requested? Or did it work only halfway, rendering the whole
"transaction" model useless?
A "halfway rollback" would be one of the most stupid things I've heard
about.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"El número de instalaciones de UNIX se ha elevado a 10,
y se espera que este número aumente" (UPM, 1972)
Karel Zak
> On Wed, 8 Oct 2003 11:28:00 -0400 (EDT) John Wells <j...@sourceillustrated.com> wrote:
>
> > It's my opinion that we should be using PG, because of the full ACID
> > support, and the license involved. A consultant my company hired before
> > bringing me in is pushing hard for MySql, citing speed and community
> > support, as well as ACID support.
>
> you should also cite conformity to standards. MySQL is significantly
> different from SQL standards in a number of regards. not that any are fully
I think very nice example is:
SELECT 'a' || 'b';
BTW, MySQL versions without transactions are unusable for 365/7/24
systems, because you cannot make backup of DB without transaction or
redo log.
Karel
--
Karel Zak <za...@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
Shridhar Daithankar
>>One of my friend lost data with mysql yesterday.. The machine was taken down for
>>disk upgrade and mysql apperantly did not commit the last insert.. OK he was
>>using myisam but still..:-)
>
>
> It sounds like that is more a problem with improper operating protocols
> than with the underlying database.
No. Problem is machine was shutdown with shutdown -h. It sends sigterm to
everybody. A good process would flsuh the buffers to disk before finishing.
Mysql didn't on that occasion.
Transactions or not, this behaviour is unacceptable for any serious app.
>
> Would PG know enough to do a commit regardless of how the database was
> shut down? A second question is whether doing a commit is what the user
> or application would always want to have happen, as it could result in a
> half-completed transaction.
Do a shutdown -h on a live database machine with pg. It will gracefully shut
itself down.
Shridhar
Karel Zak
On Thu, Oct 09, 2003 at 01:33:39PM +0200, Harald Fuchs wrote:
> In article <2003100906...@zf.jcu.cz>,
> Karel Zak <za...@zf.jcu.cz> writes:
>
> > BTW, MySQL versions without transactions are unusable for 365/7/24
> > systems, because you cannot make backup of DB without transaction or
> > redo log.
>
> something like that for ages. This tool locks all tables and can take
^^^^^
:-)
> a significant amount of time for large databases. Since many people
> don't want that, they just create a small replication slave used
> exclusively for backup.
How sure you with integrity of backup without transaction? For example
references between tables...
Karel
--
Karel Zak <za...@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
---------------------------(end of broadcast)---------------------------
Kaarel
> support, and the license involved. A consultant my company hired before
> bringing me in is pushing hard for MySql, citing speed and community
> support, as well as ACID support.
Does the consultant push "speed AND ACID" or "speed OR ACID"? My point
is that PostgreSQL is said to be harder to install/maintain/tune than
MySQL. I have been reading some MySQL mailing list and for what I see
there, using InnoDB tables (the only way to have foreign keys,
transactions, and row level locking for MySQL) makes MySQL slower and
adds complexity to tuning the database. See this thread for example
http://lists.mysql.com/mysql/148832 . So when someone says that
PostgreSQL without tuning is 5 times slower than MySQL retrieving the
same query, it is quite right to also say that MySQL InnoDB without
tuning is 5 times slower than MySQL MyISAM.
In my opinion you might consider MySQL only when you don't need the
features provided by PostgreSQL (and even then data consistency and
durability issues favor PostgreSQL) because if you need them, your
developers need to implement them and do extra work, spending more time
and money. It was already mentioned but I'll post this link again
http://sql-info.de/mysql/ . IMHO if you are not aware of these gotchas
they can also increase development time because some things are too
different from regular/logical behavior (or common sense if you will) of
any other database.
Kaarel
Bill Gribble
> Here is the simple thing about MySQL licensing. It is GPL. If you
> modify the mySQL source or you link a proprietary app to mySQL without
> a commercial license. You must distrubute your changes and or
> application as GPL or GPL compatibile.
You have two contradictory statements here, which unfortunately
represent the internal contradictions in MySQL's license (at least,
those versions after version 3.23.19, when MySQL AB adopted the current
licensing scheme).
Certainly, if MySQL is licensed under the GPL, you must distribute or
make available source code to any changed version of MySQL that you
distribute, or any other derivative works of MySQL that you distribute.
However, MySQL's stated license makes far greater requirements on those
who use MySQL.
Even though many distributors of MySQL, including the normally very
license-conscious Debian GNU/Linux, include only the GPL as its license,
there are in fact additional constraints which limit the rights that are
given by the GPL. MySQL AB's license information web page [1] includes
in plain language what their intent is, and that intent is not the GPL,
nor is it compatible with the GPL.
The non-commercial (free-of-charge) MySQL license extends the
requirement to make available source code to "your application",
regardless of whether or not your application is a derived work of
MySQL. All practical interpretations of the GPL, including the FSF's,
exclude from the requirement to distribute source code any works that
are collected by "simple aggregation", meaning they are present on the
same distribution medium or in the same distribution package as the
licensed work, but are not related to the licensed work by the sharing
of licensed components. MySQL does not distinguish between derivative
works of MySQL and those that are collected along with it by simple
aggregation.
So, for example, if I wish to sell a version of Debian with a
proprietary, closed-source installation tool (which does not use or
relate to MySQL in any way) and I wish to also include MySQL and its
source code in my distribution, I am required to get a commercial
license from MySQL. That is not consistent with the terms of the GPL
under which I received MySQL from Debian.
I don't know how to put it more plainly than that. Even though MySQL AB
claims that their product is licensed under the GPL, it is not, because
they put significant additional license terms on it that remove some
rights given by the GPL. The overall license terms of MySQL do not
meet any standard of "Free software" licenses that I know, including the
Debian Free Software Guidelines [2]. I believe that Debian and other
GNU/Linux distributions should move MySQL to their non-free sections,
along with other software that is "free for non-commercial use".
The consequences for any commercial enterprise using MySQL in any way
must be very closely examined, and certainly aren't obvious in the way
that the consequences of the GPL are obvious.
Thanks,
Bill Gribble
[1] http://www.mysql.com/products/licensing.html
[2] http://www.debian.org/social_contract#guidelines
bob parker
> Yes, I know you've seen the above subject before, so please be gentle with
> the flamethrowers.
>
> I'm preparing to enter a discussion with management at my company
> regarding going forward as either a MySql shop or a Postgresql shop.
>
> support, and the license involved. A consultant my company hired before
> bringing me in is pushing hard for MySql, citing speed and community
> support, as well as ACID support.
>
---------------------------(end of broadcast)---------------------------
Vivek Khera
OE> MySQL's licence does not require you to buy a licence for _any_
OE> commercial use, but only for commercial use where you do not release
OE> your source code under a GPL-compatible licence.
So if I write my application in python, say, and only relase the .pyc
files, I'm not linked to mysql, but I use it via the API provided by
the python runtime. The GPL does not require me to release the source
code to my application, yet I'm using mysql in a commercial setting.
I believe that mysql will demand a license fee from me in this
situation.
It is very murky with mysql.
no...@celery.tssi.com
> > than with the underlying database.
>
> No. Problem is machine was shutdown with shutdown -h. It sends sigterm to
> everybody. A good process would flsuh the buffers to disk before finishing.
> Mysql didn't on that occasion.
> Transactions or not, this behaviour is unacceptable for any serious app.
True, but was it because the shutdown scripts weren't set up properly
or does MySQL just not handle the 'kill' properly? (I would consider the
latter a serious bug.)
I still fault the operations protocol, part of what should be done in
setting up a production shop is testing various shutdown options, and it
sounds like that wasn't done in advance or they would have known to build
in extra steps for shutting down MySQL.
> Do a shutdown -h on a live database machine with pg. It will gracefully shut
> itself down.
Is that true for all OS flavors and is it dependent upon the DBA having
set up proper shutdown scripts?
I'm not trying to be argumentative here or defending MySQL, just noting
that a shutdown process that isn't tested can cause problems even with
commercial databases. And as someone who has to put up with MySQL on
occasion, I'm always looking for problem areas for the DBA.
--
Mike Nolan
---------------------------(end of broadcast)---------------------------
Alvaro Herrera
> I'm not trying to be argumentative here or defending MySQL, just noting
> that a shutdown process that isn't tested can cause problems even with
> commercial databases. And as someone who has to put up with MySQL on
> occasion, I'm always looking for problem areas for the DBA.
Well, you can convert that into an argument favoring PostgreSQL. In
Postgres, no matter what shutdown procedure you use, a committed
transaction will be a committed transaction after the power comes back,
and an uncommitted transaction will still be an uncommitted transaction,
without needing lengthy rollback procedures. If commercial systems,
including MySQL, do not work the same, it is some kind of "issue".
(Just like slow aggregates are an "issue" in Postgres just because other
systems make them work fast.)
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
---------------------------(end of broadcast)---------------------------
scott.marlowe
> no...@celery.tssi.com wrote:
>
> >>One of my friend lost data with mysql yesterday.. The machine was taken down for
> >>disk upgrade and mysql apperantly did not commit the last insert.. OK he was
> >>using myisam but still..:-)
> >
> >
> > It sounds like that is more a problem with improper operating protocols
> > than with the underlying database.
>
> No. Problem is machine was shutdown with shutdown -h. It sends sigterm to
> everybody. A good process would flsuh the buffers to disk before finishing.
> Mysql didn't on that occasion.
>
> Transactions or not, this behaviour is unacceptable for any serious app.
>
> >
> > Would PG know enough to do a commit regardless of how the database was
> > shut down? A second question is whether doing a commit is what the user
> > or application would always want to have happen, as it could result in a
> > half-completed transaction.
>
> Do a shutdown -h on a live database machine with pg. It will gracefully shut
> itself down.
If you're running on a properly setup machine (i.e. SCSI and / or battery
backed RAID cache) you can just pull the plug and pg will restart
gracefully. It's one of the standard tests.
Try this on a SCSI based machine with a journaling file system:
pgbench -i -s 10
pgbench -c 200 -t 1000000
wait a minute
start a vacuum
pull the plug
wait a minute
plug it in (turn it on if necessary)
voila, postgresql will recover gracefully with no corruption.
Now ask the consultant to do the same for MySQL. :-)
scott.marlowe
> > > It sounds like that is more a problem with improper operating protocols
> > > than with the underlying database.
> >
> > No. Problem is machine was shutdown with shutdown -h. It sends sigterm to
> > everybody. A good process would flsuh the buffers to disk before finishing.
> > Mysql didn't on that occasion.
>
> > Transactions or not, this behaviour is unacceptable for any serious app.
>
> True, but was it because the shutdown scripts weren't set up properly
> or does MySQL just not handle the 'kill' properly? (I would consider the
> latter a serious bug.)
>
> I still fault the operations protocol, part of what should be done in
> setting up a production shop is testing various shutdown options, and it
> sounds like that wasn't done in advance or they would have known to build
> in extra steps for shutting down MySQL.
>
> > Do a shutdown -h on a live database machine with pg. It will gracefully shut
> > itself down.
>
> Is that true for all OS flavors and is it dependent upon the DBA having
> set up proper shutdown scripts?
>
> I'm not trying to be argumentative here or defending MySQL, just noting
> that a shutdown process that isn't tested can cause problems even with
> commercial databases. And as someone who has to put up with MySQL on
> occasion, I'm always looking for problem areas for the DBA.
but a database should survive this kind of thing. Postgresql certainly
can survive having its power plug pulled mid transaction under heavy load.
that's what WAL is for. The fact that MySQL can be corrupted by being
shut down improperly points to a shortcoming a user should be aware of
before choosing it.
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majo...@postgresql.org
Jonathan Bartlett
are not because they are faster - it's because people care about data. If
you just want speed, use a hierarchical database, or just use an indexed
file.
However, the reason the industry switched to relational databases was
that they cared more that they had consistent data that worked with
multiple applications that was able to guarantee data integrity (i.e. -
support for views, constraints, and triggers) than they were about speed.
In fact, the first relational databases were 50x slower that their
hierarchical and network counterparts. However, the industry still
switched because data integrity and data independence is worth that much.
If your application needs speed that much more than data integrity, you
might as well just use REALLY FAST stuff like indexed files or a
hierarchical database or the Prevayler (sp?) than just use a fast
semi-relational database that doesn't support the features that people
use databases for anyway.
Jon
Ron Johnson
[snip]
> that a shutdown process that isn't tested can cause problems even with
> commercial databases. And as someone who has to put up with MySQL on
Then that's a piss-poor commercial DBMS, since that means that the
DB would be corrupt if the box crashed hard.
--
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l....@cox.net
Jefferson, LA USA
After listening to many White House, Pentagon & CENTCOM briefings
in both Gulf Wars, it is my firm belief that most "senior
correspondents" either have serious agendas that don't get shaken
by facts, or are dumb as dog feces.
Kaarel
> Does the consultant push "speed AND ACID" or "speed OR ACID"? My point
> is that PostgreSQL is said to be harder to install/maintain/tune than
> MySQL.
Erhm, I kind of missed half of my sentence or smth. Anyway the point is
that with MySQL you get *either* (speed) or (foreign keys and
transactions) not both as what seems the consultant is pushing.
Kaarel
---------------------------(end of broadcast)---------------------------
Jonathan Bartlett
> debian and using the 'free' collection of software, suddenly I'm not
> in compliance with their license. Sounds like a time-bomb waiting to
> explode.
>
I think MySQL is using deceptive language about what you can and can't do
with MySQL. They use "create an application using MySQL" as a synonym for
"modififying the source code of MySQL". Reall, it's just standard GPL -
they are just trying to muddy the waters to make buying it an easier road.
If you read at the bottom, they basically say that if you don't modify
their source code, you can still redistribute, but add some "iffy"
language to get you to fear doing so.
Jon
Jonathan Bartlett
> commercial use, but only for commercial use where you do not release
> your source code under a GPL-compatible licence.
>
> There seems to be an awful lot of confusion about the GPL. Maybe
> Microsoft's campaign has been bearing fruit in unlikely quarters...
I think the confusion comes from the fact that a database is kind of a
meta-application. The GPL does not come into play when something is used
as an external tool, but it does come into play when you link with
libraries. In the case with databases, both are _usually_ happening.
For instance, if I were to write my own MySQL driver that communicated w/
MySQL over a socket using no MySQL headers, my entire application would
not have to be GPL because it doesn't link with MySQL - it just uses it as
a tool. However, if I use MySQL's C-language driver, then my code
includes MySQL source at compile-time, and thus the binary is a derivative
work, subject to the GPL.
The waters get a bit muddier when dealing with scripting languages.
If I use Perl, and just "use DBD::MySQL;", then NO MYSQL CODE is present
in my code. I _refer_ to it, but the "use" statement is indeed my code.
When I ship my application, I'm shipping three separate parts - MySQL, the
MySQL driver, and my Perl code. The _user_, when they run the code, is
the one who combines them. As far as the GPL is concerned, the user can
combine anything they want to, so the Perl code does not have to be GPL to
be distributed.
This is different than dynamic linking. With dynamic linking, you still
have to #include the header files at compile time. So, while you could
distribute your source code under any license you choose, if you
distributed binaries you would have to distribute them GPL, because GPL
code is included in the binary through your #include.
Jon
>
> --
> Oliver Elphick Oliver....@lfix.co.uk
> Isle of Wight, UK http://www.lfix.co.uk/oliver
> GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
> ========================================
> "Let no man say when he is tempted, I am tempted of
> God; for God cannot be tempted with evil, neither
> tempteth he any man; But every man is tempted, when he
> is drawn away of his own lust, and enticed."
> James 1:13,14
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
Jonathan Bartlett
Just because you ship it to them GPL does not mean that it is publicly
accessible.
For exsample, if I have a product that I built for a customer, I would
have to give it to them under the GPL. But I also have the choice to not
give it to them AT ALL. So, they pay me to get it, and the license is the
GPL. Their other choice, if they didn't pay me, would be to not have it
at all. It's likely that I could sell this same software to multiple
entities, because the likelihood of the first company having the time,
personel, and motivation to just giving it away on the Internet are very
small.
In addition, if you make it available at stores, people will buy it for
convenience, like they do with Red Hat and Star Office.
> The reason that there is a lot of confusion is that the license
> conditions are extremely confusing.
I haven't found this to be true. Most people just don't read the license
and assume they know what it says. For a license, it's pretty
straightforward. Not as straightforward as MIT/X, but pretty
straightforward nonetheless. In fact, most of the complications come from
copyright law itself(i.e. - the definition of a derivative work), and not
the GPL.
Jon
---------------------------(end of broadcast)---------------------------
Christopher Browne
> MySQL's licence does not require you to buy a licence for _any_
> commercial use, but only for commercial use where you do not release
> your source code under a GPL-compatible licence.
That's all well and good, but isn't consistent with what MySQL AB
writes about the matter.
Their page on licensing doesn't say what you wrote; it gives quite a
different message. When they write about it, they are surely
encouraging the perception that if you are using their product either:
a) For "commercial purposes," or
b) With non-GPLed code,
they expect you to pay for "commercial" licenses.
In a world where the activities of SCO are leaving people a little
edgy, that's leaving people sensitive to the notion that they might
get sued by a company for some form of 'infringment' irrespective of
what a license written by some other organization might say. (And
those that use BSD-based systems should not feel comfortable, either.
They have been affected, in the past, by similar issues.)
If I were to be cavalier and behave that the GPL applied in 'pure'
form to MySQL, I would be more than a little concerned that I might
get a letter from MySQL AB's lawyers demanding some combination of
"cease and desist" and "pay us the money you owe." That the demand
might be frivolous would not prevent this from costing me time, legal
fees, and lost hair and sleep.
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www3.sympatico.ca/cbbrowne/oses.html
Rules of the Evil Overlord #145. "My dungeon cell decor will not
feature exposed pipes. While they add to the gloomy atmosphere, they
are good conductors of vibrations and a lot of prisoners know Morse
code." <http://www.eviloverlord.com/>
Jeffrey Melloy
On Thursday, October 9, 2003, at 01:42 AM, Shridhar Daithankar wrote:
> no...@celery.tssi.com wrote:
>
>>> One of my friend lost data with mysql yesterday.. The machine was
>>> taken down for disk upgrade and mysql apperantly did not commit the
>>> last insert.. OK he was using myisam but still..:-)
>> It sounds like that is more a problem with improper operating
>> protocols
>> than with the underlying database.
>
> No. Problem is machine was shutdown with shutdown -h. It sends sigterm
> to everybody. A good process would flsuh the buffers to disk before
> finishing. Mysql didn't on that occasion.
>
> Transactions or not, this behaviour is unacceptable for any serious
> app.
>
>> Would PG know enough to do a commit regardless of how the database
>> was shut down? A second question is whether doing a commit is what
>> the user or application would always want to have happen, as it could
>> result in a half-completed transaction.
>
> Do a shutdown -h on a live database machine with pg. It will
> gracefully shut itself down.
>
> Shridhar
>
I'm curious ... do MySQL lists talk about this as much as we do? What
do they say?
"Well, we run Slashdot."
"Well, we can "select count(*) faster"
"We have all the features they do! Nobody uses views or triggers!"
Jeff
Shridhar Daithankar
> On Thursday, October 9, 2003, at 01:42 AM, Shridhar Daithankar wrote:
>> Do a shutdown -h on a live database machine with pg. It will
>> gracefully shut itself down.
>>
>> Shridhar
>>
> I'm curious ... do MySQL lists talk about this as much as we do? What
> do they say?
>
> "Well, we run Slashdot."
> "Well, we can "select count(*) faster"
> "We have all the features they do! Nobody uses views or triggers!"
Simple question. Why do we care?
Nobody here talks about mysql on their own. Its always somebody who asks for
comparison or comment or help migrating to/from mysql etc.(Exception advocacy.
Its our job there...)
These lists are to help people who look at postgresql and do/want to use it.
Mysql discussion usually remains on periphery of being relevant. Its is
discussed because being in touch helps while doing any fair comparison.
Otherwise IMO mysql is irrelevant on any of postgresql lists. It exists, fine.
It is popular, even more fine.
In fact lately I have refused to help couple of guys who insisted on mysql. I
have better things to do than to sell postgresql/linux/<other open source
platform>. If somebody needs genuine help, they listen to polite language. If
they don't, I am off..:-)
Saves a lot of time usually..
Shridhar
Jonathan Bartlett
> "Well, we run Slashdot."
> "Well, we can "select count(*) faster"
> "We have all the features they do! Nobody uses views or triggers!"
>
"The feature is planned, but most people get along fine without it."
Jon
---------------------------(end of broadcast)---------------------------
Christopher Browne
> However, the reason the industry switched to relational databases
> was that they cared more that they had consistent data that worked
> with multiple applications that was able to guarantee data integrity
> (i.e. - support for views, constraints, and triggers) than they were
> about speed. In fact, the first relational databases were 50x
> slower that their hierarchical and network counterparts. However,
> the industry still switched because data integrity and data
> independence is worth that much.
If I understand the history of things correctly, a big part of the
reason why the industry switched from IMS to DB/2 and Oracle was that
they could live with the manyfold diminishment of performance, but
desperately needed to have the flexibility that RDBMSes bought them.
The IMS applications, where navigation and validation logic had to be
hard-coded into the applications, were getting to be too much to cope
with.
I suspect that the Telco folks are still fighting with this to some
degree even to this day; everyone I have known that has been involved
with telco billing applications have found them to be an absolute
horror. A few years ago, I observed cases of them being unable to
offer the new products that Sales were selling because they couldn't
integrate in the code to support BILLING for the new services...
There was a coworker at SHL Systemhouse that kept getting stuck back
on an infamous such project after regular promises that "this will be
the VERY LAST TIME." After 3 "last times," he quit and moved to New
Zealand so they couldn't call him again. :-)
It seems to me that what we are observing here is that "youngsters"
with neither an interest in history nor the maturity of having
experienced some "IT war wounds" are heading in the very same
directions as the IMS people of the '60s.
There are big enough challenges when we use every bit of integrity
checking that we can get our hands on; when no attempt is made to do
it, that's just disaster.
--
select 'cbbrowne' || '@' || 'libertyrms.info';
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)
Vivek Khera
SD> Do a shutdown -h on a live database machine with pg. It will
SD> gracefully shut itself down.
I think it is a timing issue. The PG has no way to notify the OS that
it has finished exiting, so if it takes a long time to exit, the OS
will ungracefully kill the DB process(es). Doesn't matter what DB (or
any other application) you're running, you *can* lose data this way.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: kh...@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Jeff MacDonald
you'll be in a consistant state. Ie: postgres will know the transaction
didn't finish, and should rollback what it was doing, when it starts up
again.
Without transactions you don't know if half of your operation completed
or all of it or etc.. pretty dangerous state to have your data in.
Or... at least this is now I understand it.
Jeff.
On Thu, 2003-10-09 at 14:30, Vivek Khera wrote:
> >>>>> "SD" == Shridhar Daithankar <shridhar_...@persistent.co.in> writes:
>
> SD> Do a shutdown -h on a live database machine with pg. It will
> SD> gracefully shut itself down.
>
>
> I think it is a timing issue. The PG has no way to notify the OS that
> it has finished exiting, so if it takes a long time to exit, the OS
> will ungracefully kill the DB process(es). Doesn't matter what DB (or
> any other application) you're running, you *can* lose data this way.
bob parker
> Yes, I know you've seen the above subject before, so please be gentle with
> the flamethrowers.
>
> I'm preparing to enter a discussion with management at my company
> regarding going forward as either a MySql shop or a Postgresql shop.
>
> It's my opinion that we should be using PG, because of the full ACID
> support, and the license involved. A consultant my company hired before
> bringing me in is pushing hard for MySql, citing speed and community
> support, as well as ACID support.
Apologies for the empty reply - my mind is on brain death so I needed to
imitate it.
I'll address only the alleged community support for MySql because you will
get much better qualified replies to your other concerns from others.
About 18 months ago I had to choose a DB for my home grown small systems.
Knowing very little about them I lurked on the both this list and a MySql
list for a couple of months.
In contrast to this list, the MySql one not only had a high proportion of
brain dead questions, there were a fair few answers of the same grade too.
I quickly decided that Postgresql was the better product by far for that and
many other reasons.
HTH
Bob
Marsh Ray
> But as far as Debian is concerned, paragraph 1 applies:
>
>1. Free use for those who are 100% GPL
>
>If your application is licensed under GPL or compatible OSI license
>approved by MySQL AB, you are free and welcome to ship any GPL software
>of MySQL AB with your application. By "application" we mean any type of
>software application, system, tool or utility. For doing this, you do
>not need a separate signed agreement with MySQL AB, because the GPL text
>is sufficient...
>
>That makes it free under the Debian Free Software Guidelines, so I have
>no grounds for requesting its removal. :-(
>
>
Just out of curiosity, what does Debian make MySQL's rather bizarre
interpretaion of the GPL:
http://www.mysql.com/documentation/mysql/bychapter/manual_Introduction.html#Copyright
--- begin quote ----
You need a commercial license:
[...]
When you distribute a non-|GPL| application that *only* works with
the |MySQL| software and ship it with the |MySQL| software. This type of
solution is considered to be linking even if it's done over a network.
--- end quote ----
"Linking over a network"? What stops some GPL'ed web server (or
commercial one for that matter) from demanding non-free licensing for
web clients that connect to it?
- Marsh
Jonathan Bartlett
> it has finished exiting, so if it takes a long time to exit, the OS
> will ungracefully kill the DB process(es). Doesn't matter what DB (or
> any other application) you're running, you *can* lose data this way.
No, writet-ahead logs prevent problems in this way.
Jon
Martin Marques
> Just out of curiosity, what does Debian make MySQL's rather bizarre
> interpretaion of the GPL:
>
> http://www.mysql.com/documentation/mysql/bychapter/manual_Introduction.html
>
> You need a commercial license:
> [...]
> When you distribute a non-|GPL| application that *only* works with
> the |MySQL| software and ship it with the |MySQL| software. This type of
> solution is considered to be linking even if it's done over a network.
>
> --- end quote ----
> "Linking over a network"? What stops some GPL'ed web server (or
> commercial one for that matter) from demanding non-free licensing for
> web clients that connect to it?
I would like to know what Debian is going to do with PHP and MySQL. There's
alot of talk about this in the PHP related lists.
PHP folks do think that there may be some sort of incompatibility between the
two licenses.
--
08:49:01 up 7 days, 18:26, 2 users, load average: 0.14, 0.18, 0.25
-----------------------------------------------------------------
Martín Marqués | mmar...@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------
scott.marlowe
> >>>>> "SD" == Shridhar Daithankar <shridhar_...@persistent.co.in> writes:
>
> SD> Do a shutdown -h on a live database machine with pg. It will
> SD> gracefully shut itself down.
>
>
> I think it is a timing issue. The PG has no way to notify the OS that
> it has finished exiting, so if it takes a long time to exit, the OS
> will ungracefully kill the DB process(es). Doesn't matter what DB (or
> any other application) you're running, you *can* lose data this way.
While it is possible to lose a non-committed transaction, WAL prevents the
database from becoming corrupted. Assuming proper fsyncing of your hard
drives (i.e. SCSI, or IDE with write cache disabled)
scott.marlowe
> El Jue 09 Oct 2003 22:44, Marsh Ray escribió:
> > Just out of curiosity, what does Debian make MySQL's rather bizarre
> > interpretaion of the GPL:
> >
> > http://www.mysql.com/documentation/mysql/bychapter/manual_Introduction.html
> >#Copyright --- begin quote ----
> >
> > You need a commercial license:
> > [...]
> > When you distribute a non-|GPL| application that *only* works with
> > the |MySQL| software and ship it with the |MySQL| software. This type of
> > solution is considered to be linking even if it's done over a network.
> >
> > --- end quote ----
> > "Linking over a network"? What stops some GPL'ed web server (or
> > commercial one for that matter) from demanding non-free licensing for
> > web clients that connect to it?
>
> I would like to know what Debian is going to do with PHP and MySQL. There's
> alot of talk about this in the PHP related lists.
> PHP folks do think that there may be some sort of incompatibility between the
> two licenses.
Basically, if you include MySQL connect libs in PHP and distribute it PHP
now falls under the GPL. Since PHP's license expressly forbids
relicensing, they are incompatible to distribute together. This was
caused by MySQL changing their connect libs from LGPL to GPL. It's why
PHP now no longer includes MySQL connect libs in their source tree.
Oliver Elphick
> I would like to know what Debian is going to do with PHP and MySQL.
You can raise the issue with Debian's mysql package maintainer
(my...@packages.debian.org) and with the mailing list
debian...@lists.debian.org.
--
Oliver Elphick Oliver....@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"He that covereth his sins shall not prosper; but whoso
confesseth and forsaketh them shall have mercy."
Proverbs 28:13
Rick Gigger
running on SQL Server and I wanted to get rid of it because it was
expensive. Didn't really do much for us that the others couldn't, and I
wanted to get rid of windows. Plus administratively SQL Server just seemed
to have a lot more weird problems than the other two. So I started porting
one of my apps simultaneously to both postgres and mysql. I got to a part
of my app that used unions. At that time mysql didn't support unions (I
realize that it does now). I was absolutely amazed. Needless to say I
dropped mysql right there and have used nothing but postgres ever since.
The learning curve was maybe a tiny, tiny bit steeper than mysql but that is
just because postgres tends to do things right and then make them simple
(for example having sequences and then adding the serial key word) whereas
mysql just makes them simple. Once I started figuring things out though I
lost any desire to ever look at mysql again because there were so many areas
where postgres excelled and mysql lacked.
crg
Vivek Khera
>> will ungracefully kill the DB process(es). Doesn't matter what DB (or
>> any other application) you're running, you *can* lose data this way.
sm> While it is possible to lose a non-committed transaction, WAL prevents the
sm> database from becoming corrupted. Assuming proper fsyncing of your hard
sm> drives (i.e. SCSI, or IDE with write cache disabled)
So you're saying it is not possible to corrupt the WAL if the process
is ungracefully killed by the OS?
Bruce Momjian
> >>>>> "sm" == scott marlowe <scott.marlowe> writes:
>
> >> will ungracefully kill the DB process(es). Doesn't matter what DB (or
> >> any other application) you're running, you *can* lose data this way.
>
> sm> While it is possible to lose a non-committed transaction, WAL prevents the
> sm> database from becoming corrupted. Assuming proper fsyncing of your hard
> sm> drives (i.e. SCSI, or IDE with write cache disabled)
>
> So you're saying it is not possible to corrupt the WAL if the process
> is ungracefully killed by the OS?
Yes, it is impossible, even if the OS crashes too.
--
Bruce Momjian | http://candle.pha.pa.us
pg...@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
scott.marlowe
> >>>>> "sm" == scott marlowe <scott.marlowe> writes:
>
> >> will ungracefully kill the DB process(es). Doesn't matter what DB (or
> >> any other application) you're running, you *can* lose data this way.
>
> sm> While it is possible to lose a non-committed transaction, WAL prevents the
> sm> database from becoming corrupted. Assuming proper fsyncing of your hard
> sm> drives (i.e. SCSI, or IDE with write cache disabled)
>
> So you're saying it is not possible to corrupt the WAL if the process
> is ungracefully killed by the OS?
No, but it doesn't matter if it is corrupted, because the corrupted part
would be at the end, where a transaction was starting, and would just get
ignored. i.e. postgresql would replay only the parts of the WAL that
were complete and showed as committed.
Tom Lane
> I think it is a timing issue. The PG has no way to notify the OS that
> it has finished exiting, so if it takes a long time to exit, the OS
> will ungracefully kill the DB process(es). Doesn't matter what DB (or
> any other application) you're running, you *can* lose data this way.
You most certainly will *not* lose data that way. Committed
transactions will stay committed, no matter how the Postgres processes die.
regards, tom lane
John Wells
how using it on multiple internal servers violates the GPL?!?:
Hi John,
Thank you for your interest in MySQL. My answers below.
> -----Original Message-----
> From: my...@sourceillustrated.com
> [mailto:my...@sourceillustrated.com]
> Sent: Wednesday, October 08, 2003 7:50 AM
> To: lice...@mysql.com
> Subject: MySQL Licensing Question, US, -unknown-
>
>
> The following form was submitted via MySQL.com feedback engine:
>
> Name: John Wells
>
> Email address: my...@sourceillustrated.com
>
> Type of interest: for company use
>
> Country: US
>
> Support contract: no
>
> Enter Your Questions, Comments, Feedback or Your Message here:
>
> I'm a little confused on the meaning of "distributing either
> externally or internally" on the license page. If we develop an
> application that uses MySql as the backend database and
> use in on our
> internal LAN, do we need to license it commmercially?
Internal distribution applies to internally distributing/installing more
than one application. If you plan to use one installation of MySQL it
would not be considered distribution and you could use if for free with
your "internally built application."
> How would this
> be in violation of the GPL?
If your application (internal or external) is licensed under the terms
of the GPL, you are allowed to distribute MySQL, also under the GPL, for
free.
What do you mean, exactly,
> by internal
> distribution?
>
> Also, if we write an application that expects MySql (like
> a web app),
> but we don't package the database with the application
> and tell the
> customer that they must download and install it, is this
> violation of
> the GPL?
Again, if your application is licensed under the terms of the GPL you
can use MySQL for free. If your application is not licensed under the
terms of the GPL, commercial non-GPL licenses are necessary. You will
need to purchase licenses under this scenario (unless you go GPL),
please review our licensing examples,
http://www.mysql.com/products/licensing-examples.html.
How are you planning to use MySQL?
Mr. Matt Fredrickson,
Sales Executive
MySQL, Inc. - www.mysql.com
Office: +1 425 390 0154
Fax: +1 425 663 2001
MySQL Featured in the Wall Street Journal:
http://webreprints.djreprints.com/785490482991.html
Bill Gribble
> But as far as Debian is concerned, paragraph 1 applies:
>
> 1. Free use for those who are 100% GPL
>
> If your application is licensed under GPL or compatible OSI license
> approved by MySQL AB, you are free and welcome to ship any GPL software
> of MySQL AB with your application. By "application" we mean any type of
> software application, system, tool or utility. For doing this, you do
> not need a separate signed agreement with MySQL AB, because the GPL text
> is sufficient...
>
> That makes it free under the Debian Free Software Guidelines, so I have
> no grounds for requesting its removal. :-(
As I understand it, that paragraph does not "clear" mysql under the
DFSG. Requirement 1 of the DFSG is:
Free Redistribution
The license of a Debian component may not restrict any party from
selling or giving away the software as a component of an aggregate
software distribution containing programs from several different
sources. The license may not require a royalty or other fee for
such sale.
The mysql license restricts the distribution of mysql if the aggregate
distribution contains non-GPL software. DFSG #1 does not allow for a
distinction between free and non-free software among the "components of
an aggregate system". Neither does the GPL make such distinctions.
The "Commercial use for everyone else" term is either (1) completely
incompatible with the GPL, or (2) completely circumventable, since if I
received MySQL sources under the GPL, under section 2.b. of the GPL I
have the obligation to use GPL (with no MySQL AB additions) for any
third party I distribute to, for any purpose. So I put my noncommercial
GPL sources for MySQL on my noncommercial FTP server, and anyone can
download and use them for any purpose, commercial or not, solely under
the terms of the GPL, because the GPL is how I got the source from MySQL
AB.
In any case, it's a stupid, self-inconsistent license and really needs
to be changed immediately.
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
Miquel van Smoorenburg
John Wells <j...@devsea.com> wrote:
>Here's an interesting response from mysql.com sales. Frankly, I don't see
>how using it on multiple internal servers violates the GPL?!?:
You're talking to a sales droid, a suit, someone whose brain
cells have died off because his tie was tied to tight.
So remember the old adage .. "never attribute to malice that
which can be adequately explained by stupidity."
Mike.
--
Never trust a statistic you didn't fake yourself.
Randolf Richardson, DevNet SysOp 29
additional comments to further demonstrate how a qualified business planner
may look at this...
>> I'm preparing to enter a discussion with management at my company
>> regarding going forward as either a MySql shop or a Postgresql shop.
>
> - PostgreSQL supports constraints. MySQL doesn't; programmers need to
> take care of that from the client side
Wow. That's so rediculous that I don't want to believe it because
this feature is just so basic.
> - Define a 32-bit field in MySQL. Insert a 64-bit number instead. Common
> sense tells you the value would be rejected. Yet MySQL happily folds it
> in and carries on its merry way.
That's unacceptable. To me, this is a complete show-stopper because I
simply won't tolerate data loss due to an idiotic design flaw.
> - Triggers: PostgreSQL yes, MySQL no. Translates into more work for your
> MySQL developers in both creating your app and moving it forward with
> each rev.
There are also circumstances where PostgreSQL will create implicit
triggers, which means to me that MySQL must be lacking in some other
features as a result of not supporting this.
> - Transactions: We've been here before. Suffice to say, MySQL+InnoDB is
> almost there. Plain ol' MySQL doesn't have it, which tells you something
> about their philosophy towards database design.
It also indicates that Transactions are new to this product, and so
one may be better off with a more experienced group of developers who've
already earned their "battle scars" as is obviously the case with
PostgreSQL.
> - Speed: mHz for mHz, MySQL has PostgreSQL beat for simple searches.
> Once you start getting complex, PostgreSQL is competitive. I think this
> speed issue is overrated: over time, PostgreSQL has sped up and MySQL
> has slowed down which is pretty impressive, considering both have added
> features from their early versions.
Do you know of any published benchmarks for this? I need to convince
some people who are hell-bent on MySQL being fast for everything that
they're mis-informed, and they refuse to take anyone's word for it.
> - Scalability: MySQL dies before PostgreSQL does. PostgreSQL under
> extreme load may slow down, but it'll finish. MySQL simply gives up.
[sNip]
I've experienced this very problem with MySQL actually. It seems that
Apache James (an open source Java-based SMTP/POP3 mail server) running on
FreeBSD will trigger this problem very quickly as soon as multiple users
attempt to send large (greater than 10 MBs) file attachments -- perhaps
JDBC is part of the problem, but in the Apache James error logs there is
indication of MySQL connectivity problems (also during busy times on
systems sending approximately 500,000 eMails per day).
--
Randolf Richardson - r...@8x.ca
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.8x.ca/
This message originated from within a secure, reliable,
high-performance network ... a Novell NetWare network.
Randolf Richardson, DevNet SysOp 29
>> Do a shutdown -h on a live database machine with pg. It will gracefully
>> shut itself down.
>
> Is that true for all OS flavors and is it dependent upon the DBA having
> set up proper shutdown scripts?
[sNip]
When I tested this on PostgreSQL on Novell NetWare 6 it shut down
gracefully. I don't see why this would be different on other Operating
Systems since the code base is essentially the same (isn't it?).
Randolf Richardson, DevNet SysOp 29
> "We have all the features they do! Nobody uses views or triggers!"
Which cave has that person been hiding in all these years? Views are a
very important part of SQL, and any SQL server that doesn't support Views is,
in my view (sorry, I couldn't resist), simply isn't suitable for large scale
applications (and even some small ones that will use a table in many
different ways).
Randolf Richardson, DevNet SysOp 29
>>how using it on multiple internal servers violates the GPL?!?:
>
> You're talking to a sales droid, a suit, someone whose brain
> cells have died off because his tie was tied to tight.
That's an official answer from the company, and it should be treated as
such. If you think an employee is spreading mis-information, then you should
contact the company directly and ask for further clarification with a short
explanation of your doubts about the information you were provided.
Making insults to discredit someone because you don't like their
official response due to their job title is a childish tactic that doesn't
help anyone.
Randolf Richardson, DevNet SysOp 29
> For exsample, if I have a product that I built for a customer, I would
> have to give it to them under the GPL. But I also have the choice to not
> give it to them AT ALL. So, they pay me to get it, and the license is
> the GPL. Their other choice, if they didn't pay me, would be to not have
> it at all. It's likely that I could sell this same software to multiple
> entities, because the likelihood of the first company having the time,
> personel, and motivation to just giving it away on the Internet are very
> small.
[sNip]
In summary, you could be charging them for some very expensive courier
services, if for which they don't pay then you won't deliver. =)
Alex Satrapa
> [sNip]
>
>>>Do a shutdown -h on a live database machine with pg. It will gracefully
>>>shut itself down.
>>
>>Is that true for all OS flavors and is it dependent upon the DBA having
>>set up proper shutdown scripts?
>
> [sNip]
>
> When I tested this on PostgreSQL on Novell NetWare 6 it shut down
> gracefully. I don't see why this would be different on other Operating
> Systems since the code base is essentially the same (isn't it?).
No it's not. Don't confuse the PostgreSQL code base with the operating
system it's running on.
On Mac OS X (desktop version, at least) there are no shutdown scripts.
All running applications are simply sent the "TERM" signal, then later
sent the "KILL" signal. Luckily enough, PostgreSQL seems to respond to
TERM by shutting down gracefully.
Totally off topic, but this lack of shutdown scripts, along with a lack
of proper package management are the two most painful faults in Mac OS X.
Alex
Randolf Richardson, DevNet SysOp 29
>>>>gracefully shut itself down.
>> When I tested this on PostgreSQL on Novell NetWare 6 it shut down
>> gracefully. I don't see why this would be different on other Operating
>> Systems since the code base is essentially the same (isn't it?).
>
> No it's not. Don't confuse the PostgreSQL code base with the operating
> system it's running on.
On NetWare if I type "Unload Postmaster.NLM" then PostgreSQL's
shutdown functions are called and PostgreSQL proceeds with a graceful
shutdown.
I just assumed that all Operating Systems that PosgreSQL has been
ported to have this type of call-back API functionality built-in for
shutdown signals.
Now isn't this a part of the PostgreSQL code base to provide the
graceful shutdown functionality when the OS attempts to shut it down?
Shridhar Daithankar
>>- Define a 32-bit field in MySQL. Insert a 64-bit number instead. Common
>>sense tells you the value would be rejected. Yet MySQL happily folds it
>>in and carries on its merry way.
> That's unacceptable. To me, this is a complete show-stopper because I
> simply won't tolerate data loss due to an idiotic design flaw.
Worse. It is no data loss. It is loss of data integrity. If I know I have lost
two hours of work, I will crib but redo it. If I know around 5% of records are
messed up by database in last 5 years but don't know which, just think where do
I stand.
>>- Speed: mHz for mHz, MySQL has PostgreSQL beat for simple searches.
>>Once you start getting complex, PostgreSQL is competitive. I think this
>>speed issue is overrated: over time, PostgreSQL has sped up and MySQL
>>has slowed down which is pretty impressive, considering both have added
>>features from their early versions.
> Do you know of any published benchmarks for this? I need to convince
> some people who are hell-bent on MySQL being fast for everything that
> they're mis-informed, and they refuse to take anyone's word for it.
Good benchmarks are hard to come by for two reasons
1. It is very difficult not to be blamed biased.
2. Featuer compensation. What if you run a postgresql benchmark with triggers
and views, how do you test it with mysql anyways?
I would suggest you to try OSDB becnhmarks
Your results will be great contribution to the community.
Or try porting pgbench to mysql innodb.
Actually I would like to see what the this benchmark does. Any prior knowledge
of the results?
>>- Scalability: MySQL dies before PostgreSQL does. PostgreSQL under
>>extreme load may slow down, but it'll finish. MySQL simply gives up.
>
> [sNip]
>
> I've experienced this very problem with MySQL actually. It seems that
> Apache James (an open source Java-based SMTP/POP3 mail server) running on
> FreeBSD will trigger this problem very quickly as soon as multiple users
> attempt to send large (greater than 10 MBs) file attachments -- perhaps
> JDBC is part of the problem, but in the Apache James error logs there is
> indication of MySQL connectivity problems (also during busy times on
> systems sending approximately 500,000 eMails per day).
Try dbmail. I am no mail admin but that is a mail server which works off
postgresql/mysql. http://www.dbmail.org
Shridhar
Randolf Richardson, DevNet SysOp 29
>>>Common sense tells you the value would be rejected. Yet MySQL happily
>>>folds it in and carries on its merry way.
>>
>> That's unacceptable. To me, this is a complete show-stopper because I
>> simply won't tolerate data loss due to an idiotic design flaw.
>
> Worse. It is no data loss. It is loss of data integrity. If I know I
> have lost two hours of work, I will crib but redo it. If I know around
> 5% of records are messed up by database in last 5 years but don't know
> which, just think where do I stand.
That is worse, thanks for your clarity. I stopped before thinking it
through this far because any kind of screw-up like this just isn't worth
the risk in my opinion -- they really need to fix that and I think they
should make it a high priority.
[sNip]
>> Do you know of any published benchmarks for this? I need to convince
>> some people who are hell-bent on MySQL being fast for everything that
>> they're mis-informed, and they refuse to take anyone's word for it.
>
> Good benchmarks are hard to come by for two reasons
>
> 1. It is very difficult not to be blamed biased.
> 2. Featuer compensation. What if you run a postgresql benchmark with
> triggers and views, how do you test it with mysql anyways?
>
> I would suggest you to try OSDB becnhmarks
>
> http://osdb.sourceforge.net/
Thanks, I'll take a look at that.
> Your results will be great contribution to the community.
If I get enough spare time, I'll consider doing this.
> Or try porting pgbench to mysql innodb.
>
> Actually I would like to see what the this benchmark does. Any prior
> knowledge of the results?
I have no idea.
[sNip]
>> I've experienced this very problem with MySQL actually. It seems that
>> Apache James (an open source Java-based SMTP/POP3 mail server) running
>> on FreeBSD will trigger this problem very quickly as soon as multiple
>> users attempt to send large (greater than 10 MBs) file attachments --
>> perhaps JDBC is part of the problem, but in the Apache James error logs
>> there is indication of MySQL connectivity problems (also during busy
>> times on systems sending approximately 500,000 eMails per day).
>
> Try dbmail. I am no mail admin but that is a mail server which works off
> postgresql/mysql. http://www.dbmail.org
I see that it doesn't support file-based mail directories for storing
messages. That's too bad, because it just won't be able to meet the
performance of well-programmed mail servers such as Mercury (uses Novell
Directory Services for the user database) or qmail (can use PostgreSQL, and
other database engines, for the user database).
Jeff Kowalczyk
feature-by-feature grid comparing the relative capabilities of Postgresql
7.4 and MySQL 4.x. It would probably be best to limit it to objective
measures such as "Supports sub-selects in UPDATE queries". Even features
that are supported by both should be listed, just so the evaluator can
make it as a known issue. A separate supplemental section offering
subjective items such as scalability anecdotes would be useful, too.
An associate starting a project expecting to use MySQL asked me about it.
I had formed my own unscientific impressions that PostgreSQL was more
appropriate for his app, but I googled in vain for an updated PostgreSQL
vs. MySQL table as described above. I only found one from 2001, and many
of the distinctions no longer applied to current versions.
Randolf Richardson, DevNet SysOp 29
>> I would suggest you to try OSDB becnhmarks
>>
>> http://osdb.sourceforge.net/
>
> Thanks, I'll take a look at that.
>
>> Your results will be great contribution to the community.
>
> If I get enough spare time, I'll consider doing this.
According to their home page, tests are "underway" for both PostgreSQL
and MySQL. I guess I won't have to worry about this since someone else is
already working on it.
Randolf Richardson, DevNet SysOp 29
> feature-by-feature grid comparing the relative capabilities of Postgresql
> 7.4 and MySQL 4.x. It would probably be best to limit it to objective
> measures such as "Supports sub-selects in UPDATE queries". Even features
> that are supported by both should be listed, just so the evaluator can
> make it as a known issue. A separate supplemental section offering
> subjective items such as scalability anecdotes would be useful, too.
>
> An associate starting a project expecting to use MySQL asked me about it.
> I had formed my own unscientific impressions that PostgreSQL was more
> appropriate for his app, but I googled in vain for an updated PostgreSQL
> vs. MySQL table as described above. I only found one from 2001, and many
> of the distinctions no longer applied to current versions.
How does this one look?
Database Server Feature Comparisons
http://www.mysql.com/information/crash-me.php
Tom Lane
> On Mac OS X (desktop version, at least) there are no shutdown scripts.
> All running applications are simply sent the "TERM" signal, then later
> sent the "KILL" signal. Luckily enough, PostgreSQL seems to respond to
> TERM by shutting down gracefully.
No "luckily" about it: that's been the standard shutdown procedure for
Unix systems since approximately forever, and the signal responses of
the Postgres backend were consciously chosen to behave well with it.
> Totally off topic, but this lack of shutdown scripts, along with a lack
> of proper package management are the two most painful faults in Mac OS X.
I dunno whether OS X is lacking in shutdown scripts or not --- but PG
is built to shut down cleanly on any moderately-standard Unix system,
whether you have a shutdown script for it or not. OS X is certainly
standard enough for this.
regards, tom lane
Bruce Momjian
> Alex Satrapa <al...@lintelsys.com.au> writes:
> > On Mac OS X (desktop version, at least) there are no shutdown scripts.
> > All running applications are simply sent the "TERM" signal, then later
> > sent the "KILL" signal. Luckily enough, PostgreSQL seems to respond to
> > TERM by shutting down gracefully.
>
> No "luckily" about it: that's been the standard shutdown procedure for
> Unix systems since approximately forever, and the signal responses of
> the Postgres backend were consciously chosen to behave well with it.
>
> > Totally off topic, but this lack of shutdown scripts, along with a lack
> > of proper package management are the two most painful faults in Mac OS X.
>
> I dunno whether OS X is lacking in shutdown scripts or not --- but PG
> is built to shut down cleanly on any moderately-standard Unix system,
> whether you have a shutdown script for it or not. OS X is certainly
> standard enough for this.
The one problem with the signal approach is how long does the system
wait before giving up on the app shutdown? Seems that should be
something controllable by the admin, but without shutdown scripts, it
isn't.
--
Bruce Momjian | http://candle.pha.pa.us
pg...@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Robert Treat
questions you might have. Getting the two communities to agree will be
tricky, for example, you would have to break down the features into
minute detail: support subselects in SELECT clause, supports subselects
in FROM clause, supports subselects in WHERE clause.
then theres also the areas where the two project simply disagree... one
area is (something like) supporting 1 -- 1 = 0 i think, which mysql
supports but we dont. (course neither does the spec...)
and finally you need to work out how your going to define supporting
something. In postgresql we have basically two levels of supported
functionality... coded but not released, and released code. in mysql
they have alpha, beta, gamma... maybe more? and they have "plugins" that
might be needed in some functionality (think innodb for transactions,
and let's gloss over whether their implementation is acid compliant)
so just be prepared if your going to do it. also, if you do do it, i'd
like to see a feature comparison against some more interesting
candidates, like oracle or informix
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Tom Lane
> The one problem with the signal approach is how long does the system
> wait before giving up on the app shutdown? Seems that should be
> something controllable by the admin, but without shutdown scripts, it
> isn't.
I believe 20 seconds is the standard number --- that's plenty for
Postgres. (I know that it is about 20 seconds on OS X, because
that's how much time tended to get added to the shutdown procedure
back when OS X 10.0 had that shutdown bug that prevented the postmaster
from forking a shutdown subprocess.)
The fact that the number isn't readily configurable is indeed a PITA.
In a previous lifetime I ran a data-collection application that needed
more than 20 seconds to shut down, and so would not exit cleanly if
you didn't have a shutdown script step that would wait for it. But
I don't see it as a problem for Postgres.
regards, tom lane
---------------------------(end of broadcast)---------------------------
Jan Wieck
> Good benchmarks are hard to come by for two reasons
>
> 1. It is very difficult not to be blamed biased.
> 2. Featuer compensation. What if you run a postgresql benchmark with triggers
> and views, how do you test it with mysql anyways?
Good benchmark implementations you mean.
If you look for example at the TPC-W definitions, they define an
artificial bookstore web interface, from what communications have to be
encrypted down to what consitency constraints have to be guaranteed.
They do not force you to implement these constraints in any particular
way or tell you what part of the application logic has to run where. If
you're using PostgreSQL, you are absolutely fine implementing whatever
makes sense as a view, a stored procedure, whatever comes handy. Of
course, for the comparision to that other databaze, you have to
implement all these requirements in your middleware ... and then you get
into this biased blaming and so on and so forth.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanW...@Yahoo.com #
Joshua D. Drake
>I believe 20 seconds is the standard number --- that's plenty for
>Postgres.
>
that will stop the main postmaster from dying on TERM. However the
machine will eventually kill it hard and thus could produce during restart.
Sincerely,
Joshua Drake
> (I know that it is about 20 seconds on OS X, because
>that's how much time tended to get added to the shutdown procedure
>back when OS X 10.0 had that shutdown bug that prevented the postmaster
>from forking a shutdown subprocess.)
>
>The fact that the number isn't readily configurable is indeed a PITA.
>In a previous lifetime I ran a data-collection application that needed
>more than 20 seconds to shut down, and so would not exit cleanly if
>you didn't have a shutdown script step that would wait for it. But
>I don't see it as a problem for Postgres.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majo...@postgresql.org)
>
>
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - j...@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
Tom Lane
>> I believe 20 seconds is the standard number --- that's plenty for
>> Postgres.
>>
> Not always. More than once I have had a postgresql connection hung up
> that will stop the main postmaster from dying on TERM. However the
> machine will eventually kill it hard and thus could produce during restart.
Seems fine to me. Otherwise such a hangup could prevent system shutdown
indefinitely, which is a Bad Thing when your UPS batteries have thirty
seconds left in 'em ...
You will get a WAL replay at restart in that scenario, but your data
should be perfectly safe.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majo...@postgresql.org
Alex Satrapa
> "Joshua D. Drake" <j...@commandprompt.com> writes:
>>Not always. More than once I have had a postgresql connection hung up
>>that will stop the main postmaster from dying on TERM. However the
>>machine will eventually kill it hard and thus could produce during restart.
>
>
> Seems fine to me. Otherwise such a hangup could prevent system shutdown
> indefinitely, which is a Bad Thing when your UPS batteries have thirty
> seconds left in 'em ...
The thing that bothers me is that the OS will 'KILL' instead of 'TERM'
when applications haven't gone away fast enough. If it takes PostgreSQL
21 seconds to finish shutting down cleanly, it's taken too long.
Using a shutdown script, most OSes will wait for the script to terminate
before going into TERM/wait/KILL mode.
I've been told that apparently Mac OS X does support shutdown scripts,
so I'll experiment a little with them over the next day or so, and
respond to this message once I've got some conclusive evidence either way.
Scott Ribe
10.0 and 10.1, but this changed starting with 10.2
--
Scott Ribe
scott...@killerbytes.com
http://www.killerbytes.com/
(303) 665-7007 voice
Christopher Browne
>> - Speed: mHz for mHz, MySQL has PostgreSQL beat for simple
>> searches. Once you start getting complex, PostgreSQL is
>> competitive. I think this speed issue is overrated: over time,
>> PostgreSQL has sped up and MySQL has slowed down which is pretty
>> impressive, considering both have added features from their early
>> versions.
>
> Do you know of any published benchmarks for this? I need to
> convince some people who are hell-bent on MySQL being fast for
> everything that they're mis-informed, and they refuse to take
> anyone's word for it.
Publishing benchmarks is more than a little troublesome.
The sorts of ways to make PostgreSQL _really shine_, performance-wise,
involves making use of features that MySQL simply doesn't have. Fancy
footwork with stored procedures, for instance.
And "they" would (somewhat rightly) object that this would represent a
test that is "intended to make MySQL fail."
And if you start publishing results, MySQL AB might be able to send
"attack lawyers" at you, irrespective of whether there's a case with
merit. Virtually all of the commercial databases have a licensing
clause that forbids publishing benchmarks without the express consent
of the vendor, and a decent case can be made that this is a legitimate
'right' for the vendor to have.
In any case, I would think it doubtful that there is anything
reasonable to present to people that are so religiously "hell-bent,"
in any case. If they don't want to believe you, they will find
excuses to disbelieve whatever results you may give them.
--
output = reverse("ofni.smrytrebil" "@" "enworbbc")
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)
Randolf Richardson
>> Do you know of any published benchmarks for this? I need to
>> convince some people who are hell-bent on MySQL being fast for
>> everything that they're mis-informed, and they refuse to take
>> anyone's word for it.
>
> Publishing benchmarks is more than a little troublesome.
>
> The sorts of ways to make PostgreSQL _really shine_, performance-wise,
> involves making use of features that MySQL simply doesn't have. Fancy
> footwork with stored procedures, for instance.
Then a different approach is needed. One idea I can think of is to
come up with a set of both simple and complex objectives, and then see
which databases yield the best results. I believe this type of testing
would reveal more useful results for someone who's faced with the task of
choosing the right database engine for the job.
> And "they" would (somewhat rightly) object that this would represent a
> test that is "intended to make MySQL fail."
Unfortunately this is what happens whenever we compare Apples to
Oranges. Let's refrain from bringing Bananas into this. ;-D
> And if you start publishing results, MySQL AB might be able to send
> "attack lawyers" at you, irrespective of whether there's a case with
They can do this regardless of what statements are made. In fact,
they could even take issue with something completely irrelevant and,
although the courts may laugh it out of the courtroom, it could be very
much like a DoS attack, but I doubt MySQL would be so bold since it would
likely be portrayed as bad publicity from the anti-corporation types who
seem to be quite easy to find in just about every open source community.
> merit. Virtually all of the commercial databases have a licensing
> clause that forbids publishing benchmarks without the express consent
> of the vendor, and a decent case can be made that this is a legitimate
> 'right' for the vendor to have.
In that case MySQL could be in a lot of legal trouble in the future
given this web page where they include comparisons with database engine
products from various vendors (e.g., Microsoft, Oracle, SyBase, etc.):
MySQL Benchmarks
http://www.mysql.com/information/benchmarks-old.html
> In any case, I would think it doubtful that there is anything
> reasonable to present to people that are so religiously "hell-bent,"
> in any case. If they don't want to believe you, they will find
> excuses to disbelieve whatever results you may give them.
Not everyone is hell-bent on brand names when it comes to determining
which products best fit the job at hand.
--
Randolf Richardson - r...@8x.ca
Vancouver, British Columbia, Canada
Please do not eMail me directly when responding
to my postings in the newsgroups.
Bruce Momjian
> [sNip]
> > For exsample, if I have a product that I built for a customer, I would
> > have to give it to them under the GPL. But I also have the choice to not
> > give it to them AT ALL. So, they pay me to get it, and the license is
> > the GPL. Their other choice, if they didn't pay me, would be to not have
> > it at all. It's likely that I could sell this same software to multiple
> > entities, because the likelihood of the first company having the time,
> > personel, and motivation to just giving it away on the Internet are very
> > small.
> [sNip]
>
> In summary, you could be charging them for some very expensive courier
> services, if for which they don't pay then you won't deliver. =)
Of course a competitor could purchase a copy or get it from a customer
and set up shop right away selling it too.
Randolf Richardson
>> In summary, you could be charging them for some very expensive courier
>> services, if for which they don't pay then you won't deliver. =)
>
> Of course a competitor could purchase a copy or get it from a customer
> and set up shop right away selling it too.
Ah, so even the GPL has a few loop holes! =D
--
Randolf Richardson - r...@8x.ca
Jan Wieck
>> And if you start publishing results, MySQL AB might be able to send
>> "attack lawyers" at you, irrespective of whether there's a case with
>
> They can do this regardless of what statements are made. In fact,
> they could even take issue with something completely irrelevant and,
> although the courts may laugh it out of the courtroom, it could be very
> much like a DoS attack, but I doubt MySQL would be so bold since it would
> likely be portrayed as bad publicity from the anti-corporation types who
> seem to be quite easy to find in just about every open source community.
You didn't follow the MySQL vs. NuSphere (aka PeerDirect) clash? It's
been even on our mailing lists, search the archives.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanW...@Yahoo.com #
Stephen Robert Norris
> [sNip]
> >> In summary, you could be charging them for some very expensive courier
> >> services, if for which they don't pay then you won't deliver. =)
> >
> > Of course a competitor could purchase a copy or get it from a customer
> > and set up shop right away selling it too.
>
> Ah, so even the GPL has a few loop holes! =D
Not really. Well, actually no. One of the goals of the GPL is to make it
possible for this very thing to happen.
I can get GPLed software (however, by paying or for free), and the
source for it and do whatever I want with it, including on-selling
copies or derived works.
The only catch is that my copies and derived works must also be licenced
under the GPL.
Stephen
Christopher Browne
> [sNip]
>>> In summary, you could be charging them for some very expensive courier
>>> services, if for which they don't pay then you won't deliver. =)
>>
>> Of course a competitor could purchase a copy or get it from a customer
>> and set up shop right away selling it too.
>
> Ah, so even the GPL has a few loop holes! =D
If you read the GPL very carefully, you may find that it was crafted
with considerable care and intent.
I _don't_ think what MySQL AB is doing with it is quite what was
intended, but the various side-effects that you see are, by and large,
quite intentional, even the ones that don't play into scenarios of
Richard Stallman as "Evil Overlord."
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','ntlug.org').
http://www.ntlug.org/~cbbrowne/spreadsheets.html
"World domination. Fast." -- Linus Torvalds
Randolf Richardson
> If you read the GPL very carefully, you may find that it was crafted
> with considerable care and intent.
Oh, please don't misunderstand me, I wasn't implying that there was
anything wrong with such a loophole; after all, some loopholes are
intentional. =)
Although I view the GPL as well-intended to ensure that free software
remains that way, I still find that the BSD License seems to be better suited
to the needs of businesses at this point in time.
> I _don't_ think what MySQL AB is doing with it is quite what was
> intended, but the various side-effects that you see are, by and large,
> quite intentional, even the ones that don't play into scenarios of
> Richard Stallman as "Evil Overlord."
The big question is this: Has the GPL been violated by MySQL?
Christopher Browne
>> I _don't_ think what MySQL AB is doing with it is quite what was
>> intended, but the various side-effects that you see are, by and
>> large, quite intentional, even the ones that don't play into
>> scenarios of Richard Stallman as "Evil Overlord."
>
> The big question is this: Has the GPL been violated by MySQL?
The MySQL AB interpretation that any use of their software under the
GPL inherits to mandating that your software be licensed under the GPL
certainly seems controversial.
<http://slashdot.org/interviews/00/05/01/1052216.shtml>
In that interview, the indication is that by separating components
into "client" and "server" bits, using CORBA, the GPL can be
circumvented because the client and server aren't "linked." Which is
the opposite of what MySQL AB is telling people.
The MySQL AB strategy doesn't seem to involve the "client-vs-server"
issue. Arguing that your client must be GPL-licensed because the
server is wouldn't fly terribly far. Instead, they only provide
_client_ software in GPL-licensed form, as _that_ would "taint" the
software you might link to it such that it would have to be
GPL-licensed.
<http://marc.theaimsgroup.com/?l=sapdb-general&m=106045880005921&w=2>
What is very interesting is that they oppose attempts to circumvent
this by someone prepared to write their own client. (The discussion
came up when SAP-DB users were distressed that they would no longer be
able to get a LGPL-licensed client library, and were discussing the
possibility of writing their own...)
"In this case, I would suspect that the intent of your middleware is
what would matter most in a court case. If the middleware appears to
mostly be in place to circumvent licensing restrictions, then it (I
believe) would not circumvent the license. If the middleware is an
abstraction layer that simply allows for convenient access to a
variety of different data sources, then the license might be
circumvented." -- Zak Greant <z...@mysql.com>
What is also very interesting is that many/most of the uses of "client
libraries" get embedded into PHP/Perl/Python modules, which leads to a
mishmash of licenses that may (as with PHP) make redistribution of the
client libraries nonpermissible.
Long and short... No, I don't see that the GPL has been "violated."
But if the GPL is intended as a 'protector/encourager of free
software,' their use of it seems to me to be about as distant from
that _intent_ as possible.
--
let name="cbbrowne" and tld="ntlug.org" in name ^ "@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/postgresql.html
If the FreeBSD team could get away with it, they would probably use
warnings like "Contains live plague bacteria. Beware the Rabid
Hippopotami. May cause nausea and vomiting."
-- Michael Lucas, re: FreeBSD-CURRENT
Randolf Richardson
>> The big question is this: Has the GPL been violated by MySQL?
>
> The MySQL AB interpretation that any use of their software under the
> GPL inherits to mandating that your software be licensed under the GPL
> certainly seems controversial.
Whether or not their interpretation is correct is less of a concern to
me than the fact that they've interpreted it in this way. The reason is
that if I develop a product that isn't licensed under the GPL, and it
becomes very popular, then I would be worried about having to defend myself
in front of some court or arbitrator.
Considering that this is more than a mere annoyance which can prove to
be very expensive and time consuming, I'd rather just avoid the whole mess
altogether by just avoiding using such a vendor's product altogether.
Of course I'll attempt to get an official response from the legal
department of such a company before jumping to any conclusions. In the
case of MySQL, if I wanted to develop a project that was not open source
and didn't comply with the GPL, I'd send a letter (or eMail) to MySQL and
ask for clarity on what my obligations would be with regards to their
licensing and my product (and would also include a general outline of how
my product will use MySQL). If I don't like the obligations, then I'll
just not use their product (unless they're willing to make an exception for
me), but in the end I will require a written answer be sent through the
mail, complete with signatures since it's extremely easy to create doubt in
the courts around the authenticity of an eMail when you have the right
experts on your side (such as people like me).
> <http://slashdot.org/interviews/00/05/01/1052216.shtml>
>
> In that interview, the indication is that by separating components
> into "client" and "server" bits, using CORBA, the GPL can be
> circumvented because the client and server aren't "linked." Which is
> the opposite of what MySQL AB is telling people.
>
> The MySQL AB strategy doesn't seem to involve the "client-vs-server"
> issue. Arguing that your client must be GPL-licensed because the
> server is wouldn't fly terribly far. Instead, they only provide
> _client_ software in GPL-licensed form, as _that_ would "taint" the
> software you might link to it such that it would have to be
> GPL-licensed.
It's all very complicated.
> <http://marc.theaimsgroup.com/?l=sapdb-general&m=106045880005921&w=2>
>
> What is very interesting is that they oppose attempts to circumvent
> this by someone prepared to write their own client. (The discussion
> came up when SAP-DB users were distressed that they would no longer be
> able to get a LGPL-licensed client library, and were discussing the
> possibility of writing their own...)
>
> "In this case, I would suspect that the intent of your middleware is
> what would matter most in a court case. If the middleware appears to
> mostly be in place to circumvent licensing restrictions, then it (I
> believe) would not circumvent the license. If the middleware is an
> abstraction layer that simply allows for convenient access to a
> variety of different data sources, then the license might be
> circumvented." -- Zak Greant <z...@mysql.com>
Yikes! That just hits me as rather vague. Perhaps I need to look at
it more closely and think it through when my daughter's not watching the
Teletubbies. =D
> What is also very interesting is that many/most of the uses of "client
> libraries" get embedded into PHP/Perl/Python modules, which leads to a
> mishmash of licenses that may (as with PHP) make redistribution of the
> client libraries nonpermissible.
>
> Long and short... No, I don't see that the GPL has been "violated."
>
> But if the GPL is intended as a 'protector/encourager of free
> software,' their use of it seems to me to be about as distant from
> that _intent_ as possible.
Keep in mind that (at least in Canada) contractual agreements are only
valid when an aspect called "consideration" exists, which means that both
parties benefit in some way (which must not be grossly unfair to one side).
With all this mish-mash of various licenses, I wonder how
"consideration" would fit in to it all. My feeling is that a court would
likely be considering this (along with many other factors) when examining
the bigger picture of intent in order to determine if there really was any
damage done to all parties involved. Certainly one important aspect of
such a decision would be to understand what the various license owners knew
about how the industry works at present, which would probably keep the
lawyers busy for months if not years since most are non-technical.
DISCLAIMER: I'm not a lawyer so I'm just going by assumptions based on
what I've learned about the law as a layperson over the years (and from
watching The People's Court).
Chris Travers
> Although I view the GPL as well-intended to ensure that free software
> remains that way, I still find that the BSD License seems to be better
suited
> to the needs of businesses at this point in time.
>
As long as we are on the subject of licenses, here is my point of view:
Different licenses for different businesses. I am also trying to show why
PostgreSQL's licensing puts it in a good position to take advantage of
MySQL's mistakes.
Open source licenses really break down into three main groups each of which
do a good job of serving the needs of certain types of businesses, and each
group has its major success stories...
1) GPL-- includes a few derivative licenses as well from the FSF and
others. Best success stories are Linux and the GCC. I personally doubt
that IBM would be hiring so many developers to work on the Linux kernel of
Sun could take the code and incorporate it into Solaris. Major business
benefit for the GPL.
2) BSD/MIT class of licenses. Success stories include BIND and Apache.
Helps build a wider community of proprietary and open source developers.
3) Alladin Public License and spinn-offs. The APL is designed to allow the
software to be used in other open source projects, and be distributed free
of charge. However, if MAY NOT be distributed for a fee or tied to services
without additional permission from the vendor. This has the business
benefit of ensuring greater royalites. There have been several success
stories here (iirc. Ghostscript was once and may still be released under
this license, as is PDFLib).
The big issue with licensing here, however, is the fact that MySQL, by
releasing the client libraries uder the GPL has essentially said that any
developers building proprietary apps must buy expensive licenses from them.
This is similar to what Trolltech has done with QT. The result is that,
although these products (MySQL and QT) have large open source followings,
the are not making large inroads into corporate space, and will likely never
do so when there are more free alternatives to be had (PostgreSQL, GTK+,
etc).
Now, the MySQL issues can be easily circumvented. One could relatively
easily write (in PHP), a GPL'd middle component which would provide a simple
SOAP interface for MySQL, and then use proprietary apps to connect to it--
one could even distribute the MySQL client libs without infracting on the
license in that way, but it is too much overhead and quite frankly work when
there are better alternatives.
The GPL was designed with the idea that programs would be relatively
self-contained, and that non-GPL'd programs could easily interact with them.
The other licenses make no such assumption. And in order to be competitive
in the corporate workspace, GPL'd programs need to be self-contained.
A good example of this problem was a program I have been developign for a
couple years called HERMES. It is a CRM/ERP platform that (still) supports
both MySQL and PostgreSQL. The homepage is at
http://hermesweb.sourceforge.net. The program is licensed under the GPL,
and I do not have the right to change that since others have contributed
code. The problem is that at the moment, the program is NOT self-contained,
so any extensions, new interfaces, etc. must also be GPL'd. This severely
limits the community that can find the program useful. The solution is to
add a set of basic interfaces which will allow non-GPL'd programs to talk to
the server. The current approach is to create a set of Database Level API's
(Stored Proceedures), LDAP bindings, and web services. In this way, we hope
to allow the program to become the center of a larger community.
Also, even with BSD licenses, there is a strong incentive to share code,
since it ensures that the burden of maintenance is minimized. Therefore the
BSD license is not so weak as many GPL zealots would like to think.
The resulting situation is that MySQL has some licensing and technical
issues that make it a very bad fit for enterprise use. PostgreSQL is both
more free (in that closed source programs can CONNECT to it) and technically
ahead of MySQL. It is also more rugged and performs better under real
circumstances. For this reason, I cannot think of a company (aside from web
hosting services) choosing MySQL over PostgreSQL.
Web hosting services are a special exception, and I think that we could
provide better tools for managing hosted accounts.
Best WIshes,
Chris Travers
Randal L. Schwartz
Chris> The resulting situation is that MySQL has some licensing and
Chris> technical issues that make it a very bad fit for enterprise
Chris> use. PostgreSQL is both more free (in that closed source
Chris> programs can CONNECT to it) and technically ahead of MySQL. It
Chris> is also more rugged and performs better under real
Chris> circumstances. For this reason, I cannot think of a company
Chris> (aside from web hosting services) choosing MySQL over
Chris> PostgreSQL.
The biggest advantage MySQL still has over PostgreSQL is the same
advantage Microsoft has over Unix - entrenchment, both in
software and mindshare.
The marketplace often does the right thing, but when one "was right"
thing dominates the market, the "new right" thing rarely has an easy
time.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Christopher Browne
> Of course I'll attempt to get an official response from the
> legal department of such a company before jumping to any
> conclusions. In the case of MySQL, if I wanted to develop a project
> that was not open source and didn't comply with the GPL, I'd send a
> letter (or eMail) to MySQL and ask for clarity on what my
> obligations would be with regards to their licensing and my product
> (and would also include a general outline of how my product will use
> MySQL).
I'm reasonably sure that their answer would point you to the "brief
description," namely:
"This is our licensing policy in brief: Our software is 100% GPL,
and if yours is also 100% GPL (or OSI compliant), then you never
have to pay us for the licences. In all other instances, you are
better served by our commercial licence."
Their "licensing page" says it quite explicitly:
"To anyone in doubt, we recommend the commercial licence. It is
never wrong."
Which gives the pretty clear underlying message:
It's not really "open source" or "free software;" to anyone in doubt,
reality is that it's traditionally-licensed commercial software, at
several hundred dollars a pop.
I can't see them being particularly interested in giving explanations
that would lead to people _not_ sending in a cheque...
>> <http://marc.theaimsgroup.com/?l=sapdb-general&m=106045880005921&w=2>
>
> Yikes! That just hits me as rather vague. Perhaps I need to
> look at it more closely and think it through when my daughter's not
> watching the Teletubbies. =D
It was a pretty stunning claim to see, yes, indeed...
> Keep in mind that (at least in Canada) contractual agreements
> are only valid when an aspect called "consideration" exists, which
> means that both parties benefit in some way (which must not be
> grossly unfair to one side).
In the US, I believe it is common for contracts to have a clause
reading something like "with the exchange of one dollar plus other
valuable consideration."
I don't see it being a big problem to consider that there is some kind
of benefit to both sides in the use of free software.
- The use of the software is presumably somewhat valuable to the
users;
- If the producers of the software do not receive an express "value,"
the fact that they offered it freely for use would make it seem very
peculiar for them to complain of abuse.
> With all this mish-mash of various licenses, I wonder how
> "consideration" would fit in to it all. My feeling is that a court
> would likely be considering this (along with many other factors)
> when examining the bigger picture of intent in order to determine if
> there really was any damage done to all parties involved. Certainly
> one important aspect of such a decision would be to understand what
> the various license owners knew about how the industry works at
> present, which would probably keep the lawyers busy for months if
> not years since most are non-technical.
In the case of the "M guys," it isn't likely to be Canadian law that
would be relevant, in that the company is based in Sweden.
In the case of PostgreSQL, the lack of a "legal team" would suggest
that the 'relevant jurisdiction' for any legal conflict would likely
be established by whomever started a case...
> DISCLAIMER: I'm not a lawyer so I'm just going by assumptions based
> on what I've learned about the law as a layperson over the years
> (and from watching The People's Court).
Good 'ol Judge Wapnner... :-)
Of course, he's expressing a parody of US law, which, in a number of
ways, is conspicuously different from Canadian law, just as the
respective political processes are rather different. (Canada, by use
of low-tech voting processes, seems to have a vastly more robust
electoral process due to the absence of such problems as "hanging
chad." On the other hand, prime ministers can behave as near
dictators during their tenures, absent of the US "checks and
balances"...)
And in the post-OJ era, it is pretty evident that a vital component is
that he who has the most expensive team of lawyers and/or lobbyists
will substantially influence the process. This month, we're seeing
the "entertainment" of what's going on with SCO and Michael Jackson,
and it is evident that there is _massive_ perversity going on in both
cases, irrespective of the factual merits of the cases. Whether MJ's
"Truly Bad" or not, he's pretty loopy.
And the recent threats against BSD projects demonstrates that NO free
software project can consider itself safe from legal attack.
If the Debian project had decided to drop PostgreSQL due to "paranoid
readings" of its license, that might be pooh-poohed as the ravings of
GPL fans. It is most interesting when it's the OpenBSD guys that turn
up the paranoid ones this week...
--
select 'cbbrowne' || '@' || 'cbbrowne.com';
http://www3.sympatico.ca/cbbrowne/languages.html
Oh, boy, virtual memory! Now I'm gonna make myself a really *big*
RAMdisk!
Randolf Richardson
> The biggest advantage MySQL still has over PostgreSQL is the same
> advantage Microsoft has over Unix - entrenchment, both in
> software and mindshare.
Ah yes, but in Microsoft's case many people are hate them because
there is a perception that their products are the only choice.
At least with MySQL most users are generally happy with it, so the
situation, although very similar, will be an even more difficult battle in
this database world because there is a general consensus among many Windows
OS users to move to something else (be it Linux-based or not) as long as it
doesn't prevent them from doing all the things they need to do with their
computer on a daily basis.
SQL standards are certainly a move in the right direction with regards
to preventing the same drastic situation Microsoft has created from
occurring, but since this isn't 100% possible at this time it should at
least be a goal that's promoted throughout the community so as to ensure an
interoperable future -- those who resist it can be questioned about their
motives since it will obviously result in preventing compatibility which
would make it more difficult for users to switch between RDBMSes.
> The marketplace often does the right thing, but when one "was right"
> thing dominates the market, the "new right" thing rarely has an easy
> time.
The marketplace "used to" do the right thing. Now the vast majority
of decision makers are impressed by fancy looking marketing campaigns and
stupidly believe everything that's published by well-known brand names,
even when no brand name loyalty exists. The worst problem with regards to
this is that decisions are often made based on "what the majority of other
people are supposedly doing" rather than "what actually best fits the needs
of the project."