| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: Missing data_sync_elevel() for some calls of pg_fsync()? |
| Date: | 2019-12-02 05:45:53 |
| Message-ID: | CAMsr+YGkAmdjhTwW1a4AbJsu-oLfMHcNeRW=jXqkQ6d=H3Ly3A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2 Dec 2019 at 13:43, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> 1. Some code opens a file, writes some stuff to it, closes, and then
> fsyncs it, and if that fails and and it ever retries it'll redo all of
> those steps again. We know that some kernels might have thrown away
> the data, but we don't care about the copy in the kernel's cache
> because we'll write it out again next time around.
>
Can we trust the kernel to be reporting the EIO or ENOSPC only from
writeback buffers for the actual file we're fsync()ing though? Not from
buffers it flushed while performing our fsync() request, failed to flush,
and complained about?
I'm not confident I want to assume that.
--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2019-12-02 05:52:28 | Re: Add a GUC variable that control logical replication |
| Previous Message | Thomas Munro | 2019-12-02 05:43:23 | Re: Missing data_sync_elevel() for some calls of pg_fsync()? |