Skip site navigation (1) Skip section navigation (2)

Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: guoping(dot)zhang(at)nec(dot)com(dot)au
Cc: pgsql-performance(at)postgresql(dot)org, "'Guoping Zhang (E-mail)'" <guopingz(at)nstc(dot)nec(dot)com(dot)au>
Subject: Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql
Date: 2006-04-28 04:56:48
Message-ID: 25291.1146200208@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
"Guoping Zhang" <guoping(dot)zhang(at)nec(dot)com(dot)au> writes:
> a) The tests consists of ten thousands very small transactions, which are
> not grouped, that is why so slow with compare to set fsync off.

Yup.

> c) wal_sync_method is set to 'open_datasync', which is fastest among the
> four, right?

Well, is it?  You shouldn't assume that without testing.

> Looks like, if we have to set fsync be true, we need to modify our
> application.

Yes, you should definitely look into batching your operations into
larger transactions.  On normal hardware you can't expect to commit
transactions faster than one per disk revolution (unless they're coming
from multiple clients, where there's a hope of ganging several parallel
commits per revolution).

Or buy a disk controller with battery-backed write cache and put your
faith in that cache surviving a machine crash.  But don't turn off fsync
if you care about your data.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Guoping ZhangDate: 2006-04-28 05:01:17
Subject: Re: how unsafe (or worst scenarios) when setting fsync
Previous:From: Guoping ZhangDate: 2006-04-28 04:43:26
Subject: Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group