Re: Humor me: Postgresql vs. MySql (esp. licensing)
От | scott.marlowe |
---|---|
Тема | Re: Humor me: Postgresql vs. MySql (esp. licensing) |
Дата | |
Msg-id | Pine.LNX.4.33.0310090739190.15891-100000@css120.ihs.com обсуждение исходный текст |
Ответ на | Re: Humor me: Postgresql vs. MySql (esp. licensing) (Shridhar Daithankar <shridhar_daithankar@persistent.co.in>) |
Список | pgsql-general |
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. :-)
В списке pgsql-general по дате отправления: