| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Can we trust fsync? |
| Date: | 2013-11-21 01:43:53 |
| Message-ID: | 27503.1384998233@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> The amount of change in write reliablity behaviour in Linux across
> kernel versions, file systems and storage abstraction layers is worrying
> - different results for LVM vs !LVM, md vs !md, ext3 vs other, etc.
Well, we pretty much *have to* trust fsync --- there's not a lot we can
do if the kernel doesn't get this right. My takeaway is that you don't
want to be running a production database on bleeding-edge kernels or
filesystem stacks. If you want to use Linux, use a distro from a vendor
with a track record for caring about stability. (I'll omit the commercial
for my former employers, but ...)
Also, it's not that hard to do plug-pull testing to verify that your
system is telling the truth about fsync. This really ought to be part
of acceptance testing for any new DB server.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2013-11-21 02:03:12 | Re: UNNEST with multiple args, and TABLE with multiple funcs |
| Previous Message | Rodolfo Campero | 2013-11-21 01:39:49 | Re: information schema parameter_default implementation |