Thread: Humor me: Postgresql vs. MySql (esp. licensing)
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
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 rwelty@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
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 Oliver.Elphick@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
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
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 majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > >
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)"...
Re: Humor me: Postgresql vs. MySql (esp. licensing)
From
merlyn@stonehenge.com (Randal L. Schwartz)
Date:
>>>>> "Shridhar" == Shridhar Daithankar <shridhar_daithankar@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 <merlyn@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!
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.
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 Oliver.Elphick@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
> > 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
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 Oliver.Elphick@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
>>>>> "OE" == Oliver Elphick <olly@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: khera@kciLink.com Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
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)
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 majordomo@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
On Wed, 2003-10-08 at 20:28, Vivek Khera wrote: > >>>>> "OE" == Oliver Elphick <olly@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 Oliver.Elphick@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
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 pgman@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
> 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
On Wed, Oct 08, 2003 at 07:03:19PM -0500, nolan@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)
> 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
On Wed, Oct 08, 2003 at 09:43:04PM -0500, nolan@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)
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 <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
nolan@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
In article <20031009030518.GD8265@dcc.uchile.cl>, Alvaro Herrera <alvherre@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.
In article <20031009061602.GB8513@zf.jcu.cz>, Karel Zak <zakkr@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.
On Thu, Oct 09, 2003 at 01:33:39PM +0200, Harald Fuchs wrote:
> In article <20031009061602.GB8513@zf.jcu.cz>,
> Karel Zak <zakkr@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 <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
MySQL is not free software. Re: Humor me: Postgresql vs. MySql (esp. licensing)
From
Bill Gribble
Date:
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
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. >
>>>>> "OE" == Oliver Elphick <olly@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.
> > 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
On Thu, Oct 09, 2003 at 08:33:12AM -0500, nolan@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>)
On Thu, 9 Oct 2003, Shridhar Daithankar wrote: > nolan@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. :-)
On Thu, 9 Oct 2003 nolan@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.
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
On Thu, 2003-10-09 at 08:33, nolan@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. ron.l.johnson@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.
> 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
> 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 Oliver.Elphick@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 >
El Jue 09 Oct 2003 08:33, Harald Fuchs escribió:
> In article <20031009061602.GB8513@zf.jcu.cz>,
>
> Karel Zak <zakkr@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 | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------
On Thursday, October 9, 2003, at 01:42 AM, Shridhar Daithankar wrote: > nolan@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
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
> > "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
>>>>> "SD" == Shridhar Daithankar <shridhar_daithankar@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: khera@kciLink.com Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
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 <shridhar_daithankar@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.
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
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/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
> 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: khera@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 >
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. -- 08:49:01 up 7 days, 18:26, 2 users, load average: 0.14, 0.18, 0.25 ----------------------------------------------------------------- Martín Marqués | mmarques@unl.edu.ar Programador, Administrador, DBA | Centro de Telematica Universidad Nacional del Litoral -----------------------------------------------------------------
On Thu, 9 Oct 2003, Vivek Khera wrote: > >>>>> "SD" == Shridhar Daithankar <shridhar_daithankar@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)
On Fri, 10 Oct 2003, Martin Marques wrote: > 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.
On Fri, 2003-10-10 at 12:54, Martin Marques wrote: > 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 (mysql@packages.debian.org) and with the mailing list debian-legal@lists.debian.org. -- Oliver Elphick Oliver.Elphick@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
My experience with mysql and postgres was this. I had some apps that were 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 ----- Original Message ----- From: "bob parker" <bob_parker@dodo.com.au> To: "John Wells" <jb@sourceillustrated.com>; <pgsql-general@postgresql.org> Sent: Thursday, October 09, 2003 5:12 PM Subject: Re: [GENERAL] Humor me: Postgresql vs. MySql (esp. licensing) > 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 >
>>>>> "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? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Vivek Khera wrote: > >>>>> "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 pgman@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
On Fri, 10 Oct 2003, Vivek Khera wrote: > >>>>> "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.
olly@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/>
johnnyb@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)
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!
Vivek Khera <khera@kcilink.com> writes:
> 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
On Wed, 2003-10-08 at 11:29, 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. :-(
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.
Here's an interesting response from mysql.com sales. Frankly, I don't see 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: mysql@sourceillustrated.com > [mailto:mysql@sourceillustrated.com] > Sent: Wednesday, October 08, 2003 7:50 AM > To: licensing@mysql.com > Subject: MySQL Licensing Question, US, -unknown- > > > The following form was submitted via MySQL.com feedback engine: > > Name: John Wells > > Email address: mysql@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
In article <39092.172.16.2.8.1065670971.squirrel@mail.devsea.com>, John Wells <jb@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.
Re: Humor me: Postgresql vs. MySql (esp. licensing)
From
"Randolf Richardson, DevNet SysOp 29"
Date:
[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?).
--
Randolf Richardson - rr@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.
Re: Humor me: Postgresql vs. MySql (esp. licensing)
From
"Randolf Richardson, DevNet SysOp 29"
Date:
[sNip]
> "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 - rr@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.
Re: Humor me: Postgresql vs. MySql (esp. licensing)
From
"Randolf Richardson, DevNet SysOp 29"
Date:
>>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.
[sNip]
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 - rr@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 wrote: > [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
Alex Satrapa <alex@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.
regards, tom lane
Tom Lane wrote: > Alex Satrapa <alex@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 pgman@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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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
>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. 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 majordomo@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 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
"Joshua D. Drake" <jd@commandprompt.com> writes:
>> 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
Mac OS X Shutdown Scripts? (was Re: Humor me: Postgresql vs. MySql (esp. licensing))
From
Alex Satrapa
Date:
Tom Lane wrote: > "Joshua D. Drake" <jd@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.
> On Mac OS X (desktop version, at least) there are no shutdown scripts. 10.0 and 10.1, but this changed starting with 10.2 -- Scott Ribe scott_ribe@killerbytes.com http://www.killerbytes.com/ (303) 665-7007 voice
Re: Humor me: Postgresql vs. MySql (esp. licensing)
From
"Randolf Richardson, DevNet SysOp 29"
Date:
>>>>Do a shutdown -h on a live database machine with pg. It will
>>>>gracefully shut itself down.
[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.
[sNip]
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?
--
Randolf Richardson - rr@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.