From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Arthur Zakirov <zaartur(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add pg_file_sync() to adminpack |
Date: | 2020-01-13 14:39:32 |
Message-ID: | CAOBaU_a42xtefSExpKqoxRwbGav6J7_nr-sR+gE5Phr=L6CFvA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 13, 2020 at 2:46 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Sat, Jan 11, 2020 at 02:12:15AM +0900, Fujii Masao wrote:
> > I'm not sure if returning false with WARNING only in some error cases
> > is really good idea or not. At least for me, it's more intuitive to
> > return true on success and emit an ERROR otherwise. I'd like to hear
> > more opinions about this. Also if returning true on success is rather
> > confusing, we can change its return type to void.
>
> An advantage of not issuing an ERROR if that when working on a list of
> files (for example a WITH RECURSIVE on the whole data directory?), you
> can then know which files could not be synced instead of seeing one
> ERROR about one file, while being unsure about the state of the
> others.
Actually, can't it create a security hazard, for instance if you call
pg_file_sync() on a heap file and the calls errors out, since it's
bypassing data_sync_retry?
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2020-01-13 14:49:51 | Re: [PATCH] distinct aggregates within a window function WIP |
Previous Message | Tom Lane | 2020-01-13 14:22:06 | Re: Add FOREIGN to ALTER TABLE in pg_dump |