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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Newbie question: OT
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Data Corruption in case of abrupt failure