Re: Data Corruption in case of abrupt failure
От | scott.marlowe |
---|---|
Тема | Re: Data Corruption in case of abrupt failure |
Дата | |
Msg-id | Pine.LNX.4.33.0403170925560.10668-100000@css120.ihs.com обсуждение исходный текст |
Ответ на | Re: Data Corruption in case of abrupt failure (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Data Corruption in case of abrupt failure
Re: Data Corruption in case of abrupt failure |
Список | pgsql-general |
On Tue, 16 Mar 2004, Tom Lane wrote: > "Keith C. Perry" <netadmin@vcsn.com> writes: > > I've read threads like this before and because I've never lost data on > > servers with IDE drives after doing some basic torture tests > > (e.g. pulling the plug in the middle of an update et al), I don't > > think I've paid close enough attention. > > On many IDE drives it is possible to turn write caching on and off with > some incantation involving "hdparm" (don't have the details but you can > probably find 'em in the list archives). Possibly your system is > already configured safely. hdparm -W0 /dev/hda > > Is there some definite way someone can test their IDE drives so see > > whether or not they are "lying" about write completions? > > What I'd suggest is to set up a simple test involving a long string of > very small transactions (a bunch of separate INSERTs into a table with > no indexes works fine). Time it twice, once with "fsync" enabled and > once without. If there's not a huge difference, your drive is lying. pgbench is a nice candidate for this. pgbench -c 100 -t 100000
В списке pgsql-general по дате отправления: