| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Postgres, fsync, and OSs (specifically linux) |
| Date: | 2018-04-30 02:17:38 |
| Message-ID: | 20180430021738.2zip3pfovzm6bpjc@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2018-04-30 10:14:23 +0800, Craig Ringer wrote:
> Meanwhile, do we know if, on Linux 4.13+, if we get a buffered write
> error due to dirty writeback before we close() a file we don't
> fsync(), we'll get the error on close()?
Not quite sure what you're getting at with "a file we don't fsync" - if
we don't, we don't care about durability anyway, no? Or do you mean
where we fsync in a different process?
Either way, the answer is mostly no: On NFS et al where close() implies
an fsync you'll get the error at that time, otherwise you'll get it at
the next fsync().
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2018-04-30 02:46:00 | Re: Postgres, fsync, and OSs (specifically linux) |
| Previous Message | Craig Ringer | 2018-04-30 02:14:23 | Re: Postgres, fsync, and OSs (specifically linux) |