| From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
| Cc: | Stephen Tyler <stephen(at)stephen-tyler(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Excessive (and slow) fsync() within single transaction |
| Date: | 2009-12-09 21:54:53 |
| Message-ID: | dcc563d10912091354u58ce2591w7379bab5ff065d43@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, Dec 9, 2009 at 2:35 PM, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> wrote:
> Scott Marlowe wrote:
>> Actually, it's usually the drives that lie about fsync, especially
>> consumer grade (and some server grade) SATA / PATA drives are known
>> for this.
>
> I'm still looking for any evidence of any drive that lies.
I've tested drive in the past (when PATA roamed the land, and 80Gig
drives were huge) and could most certainly induce db corruption by
starting pgbench with -c 100, forcing a checkpoing, and then pulling
the plug. Turning off the write cache (ok all cache I guess) on those
drives made them capable of surviving the power plug being pulled.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andy Shellam (Mailing Lists) | 2009-12-09 22:29:37 | Re: pgAdmin in 8.4 installation uses tools from 8.3 installation |
| Previous Message | Greg Smith | 2009-12-09 21:49:26 | Re: Excessive (and slow) fsync() within single transaction |