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