From: Greg Smith <greg@2ndquadrant.com>
To: Yeb Havinga <yebhavinga@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ross J. Reedstrom <reedstrm@rice.edu>
Cc: pgsql-performance@postgresql.org
Subject: Re: mysql to postgresql, performance questions
Date: Wed, 24 Mar 2010 08:09:50 -0400
Message-ID: <4BAA010E.3000101@2ndquadrant.com> (raw)
In-Reply-To: <4BA9D39B.6020103@gmail.com>
References: <4BA23936.2030507@gmail.com>
<4BA596D2.4050406@squeakycode.net>
<20100323185232.GD6662@rice.edu>
<5342.1269372121@sss.pgh.pa.us>
<4BA934B9.9070401@2ndquadrant.com>
<4BA9D39B.6020103@gmail.com>
Yeb Havinga wrote:
> Greg Smith wrote:
>> MySQL corruption is one of the top ten cause of a MythTV system
>> crashing.
> It would be the same with PG, unless the pg cluster configuration with
> mythtv would come with a properly configured WAL - I had corrupted
> tables (and a personal wiki entry (the other mysql database in my
> house) *only* when I sometimes took the risk of not shutting down the
> machine properly when e.g. the remote was missing).
You can shutdown a PostgreSQL database improperly and it will come back
up again just fine unless a number of things have happened at just the
wrong time:
1) You've written something to disk
2) The write is sitting in in a write cache, usually on the hard drive,
but the OS believes the data has been written
3) There is a hard crash before that data is actually written to disk
Now, this certainly still happens with PostgreSQL; was just discussing
that yesterday with a client who runs an app on desktop hardware in
countries with intermittant power, and database corruption is a problem
for them. However, that's a fairly heavy write volume situation, which
is not the case with most MythTV servers. The actual window where the
WAL will not do what it's supposed to here is pretty narrow; it's easy
to trigger if you pull the plug when writing constantly, but that's not
a typical MythTV database load.
Also, moving forward, we'll see the default filesystem on more Linux
systems shift to ext4, and it's starting to lose even this
vulnerability--newer kernels will flush the data out to disk in this
situation using the appropriate drive command.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: greg@2ndquadrant.com, yebhavinga@gmail.com, tgl@sss.pgh.pa.us, reedstrm@rice.edu
Subject: Re: mysql to postgresql, performance questions
In-Reply-To: <4BAA010E.3000101@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox