| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | "Graeme B(dot) Bell" <graeme(dot)bell(at)nibio(dot)no> |
| Cc: | "Wes Vaske (wvaske)" <wvaske(at)micron(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: New server: SSD/RAID recommendations? |
| Date: | 2015-07-07 20:05:06 |
| Message-ID: | 559C30F2.3000703@iki.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 07/07/2015 10:59 PM, Graeme B. Bell wrote:
> Cache flushing isn't an atomic operation though. Even if the ordering
> is right, you are likely to have a partial fsync on the disk when the
> lights go out - isn't your FS still corrupt?
If the filesystem is worth its salt, no. Journaling filesystems for
example rely on the journal to work around that problem, and there are
other mechanisms.
PostgreSQL has exactly the same problem and uses the WAL to solve it.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Graeme B. Bell | 2015-07-07 20:33:34 | Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this? |
| Previous Message | Graeme B. Bell | 2015-07-07 19:59:54 | Re: New server: SSD/RAID recommendations? |