| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-core <pgsql-core(at)postgresql(dot)org>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful |
| Date: | 2015-05-25 15:37:59 |
| Message-ID: | CAM-w4HP+0e-CDGhrXDej0OyMFeZFmhG0=PgE8RKi_gyTAi9rPA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
What exactly is failing?
Is it that fsync is returning -1 ? Should we just ignore errors from
fsync if it happens in this stage? That might be safer than
determining which files should or shouldn't be fsynced.
That would also have an impact on people starting up on a flaky file
system perhaps. I'm imagining either a database mounted on a
filesystem with corruption trying to extract what they can or perhaps
something like an NFS filesystem with dangling .nfs files. On the one
hand limping along as best we can is the general Postgres strategy
when the filesystem starts failing but on the other hand we have had
circumstances in the past when users had a database on a network
filesystem that wasn't really ready for use yet when Postgres tried to
start up and starting up anyways didn't do them any favours.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2015-05-25 15:52:33 | Re: [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful |
| Previous Message | Stephen Frost | 2015-05-25 15:34:38 | Re: [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2015-05-25 15:52:33 | Re: [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful |
| Previous Message | Tom Lane | 2015-05-25 15:35:21 | Buggy logic in nodeIndexscan.c queue handling |