| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
|---|---|
| To: | Scott Carey <scott(at)richrelevance(dot)com> |
| Cc: | Laszlo Nagy <gandalf(at)shopzeus(dot)com>, Ivan Voras <ivoras(at)freebsd(dot)org>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: SSD + RAID |
| Date: | 2009-11-19 12:29:56 |
| Message-ID: | 4B053A44.7090700@postnewspapers.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 19/11/2009 12:22 PM, Scott Carey wrote:
> 3: Have PG wait a half second (configurable) after the checkpoint fsync()
> completes before deleting/ overwriting any WAL segments. This would be a
> trivial "feature" to add to a postgres release, I think.
How does that help? It doesn't provide any guarantee that the data has
hit main storage - it could lurk in SDD cache for hours.
> 4: Yet another solution: The drives DO adhere to write barriers properly.
> A filesystem that used these in the process of fsync() would be fine too.
> So XFS without LVM or MD (or the newer versions of those that don't ignore
> barriers) would work too.
*if* the WAL is also on the SSD.
If the WAL is on a separate drive, the write barriers do you no good,
because they won't ensure that the data hits the main drive storage
before the WAL recycling hits the WAL disk storage. The two drives
operate independently and the write barriers don't interact.
You'd need some kind of inter-drive write barrier.
--
Craig Ringer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2009-11-19 14:44:36 | Re: SSD + RAID |
| Previous Message | Scott Carey | 2009-11-19 04:39:02 | Re: SSD + RAID |