On Mon, 2 Dec 2019 at 13:43, Thomas Munro 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
On Mon, Dec 2, 2019 at 5:58 PM Michael Paquier wrote:
> I was just looking at some callers of pg_fsync(), to notice that some
> code paths don't use data_sync_elevel(). For some code paths, that's
> actually better to never PANIC (say backup_label file, logical
> decoding snapshot, lock file
Hi all,
I was just looking at some callers of pg_fsync(), to notice that some
code paths don't use data_sync_elevel(). For some code paths, that's
actually better to never PANIC (say backup_label file, logical
decoding snapshot, lock file where FATAL/LOG are used now, etc.).
However I have