By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,560 Members | 2,989 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,560 IT Pros & Developers. It's quick & easy.

Humor me: Postgresql vs. MySql (esp. licensing)

P: n/a
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.

John

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #1
Share this Question
Share on Google+
74 Replies


P: n/a
On Wed, 8 Oct 2003 11:28:00 -0400 (EDT) John Wells <jb@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".

richard
--
Richard Welty rw****@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?

http://archives.postgresql.org

Nov 12 '05 #2

P: n/a
On Wed, 2003-10-08 at 16:28, John Wells wrote:
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 Ol************@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

Nov 12 '05 #3

P: n/a
Richard Welty wrote:
On Wed, 8 Oct 2003 11:28:00 -0400 (EDT) John Wells <jb@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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #4

P: n/a
Hi John,

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:
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.

John

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #5

P: n/a
Oliver Elphick said:
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

Nov 12 '05 #6

P: n/a
>>>>> "Shridhar" == Shridhar Daithankar <sh*****************@persistent.co.in> writes:

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
<me****@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

Nov 12 '05 #7

P: n/a
On Wed, 8 Oct 2003, John Wells wrote:
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 ma*******@postgresql.org)

Nov 12 '05 #8

P: n/a
On Wed, 2003-10-08 at 17:07, John Wells wrote:
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 Ol************@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

Nov 12 '05 #9

P: n/a
In an attempt to throw the authorities off his trail, jb@sourceillustrated.com ("John Wells") transmitted:
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!
Nov 12 '05 #10

P: n/a
> > 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.


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
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #11

P: n/a
On Wed, 2003-10-08 at 17:56, Bill Gribble wrote:
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 Ol************@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 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #12

P: n/a
>>>>> "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.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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/

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #13

P: n/a
On Wed, Oct 08, 2003 at 05:29:44PM +0100, Oliver Elphick wrote:
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)

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #14

P: n/a
Hello,

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:
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.

John

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly


--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #15

P: n/a
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 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...

--
Oliver Elphick Ol************@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

Nov 12 '05 #16

P: n/a
Oliver Elphick wrote:
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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #17

P: n/a
> 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.

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

---------------------------(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

Nov 12 '05 #18

P: n/a
On Wed, Oct 08, 2003 at 07:03:19PM -0500, no***@celery.tssi.com wrote:
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)

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #19

P: n/a
> 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.
--
Mike Nolan
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #20

P: n/a
On Wed, Oct 08, 2003 at 09:43:04PM -0500, no***@celery.tssi.com wrote:
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)

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #21

P: n/a
On Wed, Oct 08, 2003 at 11:45:36AM -0400, Richard Welty wrote:
On Wed, 8 Oct 2003 11:28:00 -0400 (EDT) John Wells <jb@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/

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #22

P: n/a
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
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #23

P: n/a
In article <20*******************@dcc.uchile.cl>,
Alvaro Herrera <al******@dcc.uchile.cl> writes:
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.
Sridhar mentioned MyISAM tables - thus no transactions at all.
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?


Been there, done that. You can kill the MySQL server when it's
rolling back a huge transaction. When you restart it, it just
continues the rollback.
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #24

P: n/a
In article <20*******************@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.


Huh? People have backed up their MyISAM tables with "mysqlhotcopy" or
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.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #25

P: n/a

On Thu, Oct 09, 2003 at 01:33:39PM +0200, Harald Fuchs wrote:
In article <20*******************@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.
Huh? People have backed up their MyISAM tables with "mysqlhotcopy" or
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)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #26

P: n/a
On Wed, 2003-10-08 at 16:23, Joshua D. Drake wrote:
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




---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #27

P: n/a
On Thu, 9 Oct 2003 01:28, John Wells wrote:
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.


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #28

P: n/a
>>>>> "OE" == Oliver Elphick <ol**@lfix.co.uk> writes:

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.

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #29

P: n/a
> > 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.
--
Mike Nolan

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #30

P: n/a
On Thu, Oct 09, 2003 at 08:33:12AM -0500, no***@celery.tssi.com wrote:
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)---------------------------
TIP 8: explain analyze is your friend

Nov 12 '05 #31

P: n/a
On Thu, 9 Oct 2003, 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.


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. :-)
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #32

P: n/a
On Thu, 9 Oct 2003 no***@celery.tssi.com wrote:
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 ma*******@postgresql.org

Nov 12 '05 #33

P: n/a
One other thing to mention - the whole REASON we use relational databases
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
---------------------------(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

Nov 12 '05 #34

P: n/a
On Thu, 2003-10-09 at 08:33, no***@celery.tssi.com wrote:
[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. ro***********@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.
---------------------------(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

Nov 12 '05 #35

P: n/a
> 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.


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
---------------------------(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

Nov 12 '05 #36

P: n/a
> 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...
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 Ol************@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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #37

P: n/a
El Jue 09 Oct 2003 08:33, Harald Fuchs escribió:
In article <20*******************@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.


Huh? People have backed up their MyISAM tables with "mysqlhotcopy" or
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.


Sorry, is that suppose to be a solution?
It really freaks me out!

--
11:58:01 up 6 days, 21:35, 3 users, load average: 0.18, 0.34, 0.49
-----------------------------------------------------------------
Martín Marqués | mm******@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 12 '05 #38

P: n/a
ol**@lfix.co.uk (Oliver Elphick) writes:
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/>
Nov 12 '05 #39

P: n/a

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
---------------------------(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

Nov 12 '05 #40

P: n/a
Jeffrey Melloy wrote:
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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #41

P: n/a
>
"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)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #42

P: n/a
jo*****@eskimo.com (Jonathan Bartlett) writes:
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)
Nov 12 '05 #43

P: n/a
>>>>> "SD" == Shridhar Daithankar <sh*****************@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.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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/

---------------------------(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

Nov 12 '05 #44

P: n/a
Yes, but at least with transactions when the machine comes back up
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 <sh*****************@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.

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #45

P: n/a
On Thu, 9 Oct 2003 01:28, John Wells wrote:
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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #46

P: n/a
Oliver Elphick wrote:
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/m...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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #47

P: n/a
> 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.
No, writet-ahead logs prevent problems in this way.

Jon


--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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/

---------------------------(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

---------------------------(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

Nov 12 '05 #48

P: n/a
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/m...roduction.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.

--
08:49:01 up 7 days, 18:26, 2 users, load average: 0.14, 0.18, 0.25
-----------------------------------------------------------------
Martín Marqués | mm******@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #49

P: n/a
On Thu, 9 Oct 2003, Vivek Khera wrote:
>> "SD" == Shridhar Daithankar <sh*****************@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)
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #50

74 Replies

This discussion thread is closed

Replies have been disabled for this discussion.