On Thu, Jan 9, 2020 at 7:31 AM Fujii Masao <masao.fu...@gmail.com> wrote: > > On Mon, Jan 6, 2020 at 3:42 PM Michael Paquier <mich...@paquier.xyz> wrote: > > > > On Mon, Jan 06, 2020 at 03:20:13PM +0900, Arthur Zakirov wrote: > > > It isn't case if a file doesn't exist. But if there are no permissions on > > > the file: > > > > > > PANIC: could not open file "testfile": Permissions denied > > > server closed the connection unexpectedly > > > > > > It could be fixed by implementing a function like pg_file_sync_internal() > > > or > > > by making the function fsync_fname_ext() external. > > > > The patch uses stat() to make sure that the file exists and has no > > issues. Though it could be a problem with any kind of TOCTOU-like > > issues (looking at you, Windows, for ENOPERM), so I agree that it > > would make more sense to use pg_fsync() here with a fd opened first. > > I agree that it's not good for pg_file_sync() to cause a PANIC. > I updated the patch so that pg_file_sync() uses fsync_fname_ext() > instead of fsync_fname() as Arthur suggested. > > It's one of ideas to make pg_file_sync() open the file and directly call > pg_fsync(). But fsync_fname_ext() has already such code and > I'd like to avoid the code duplication.
This looks good to me. > Attached is the updated version of the patch. + <row> + <entry><function>pg_catalog.pg_file_sync(filename text)</function></entry> + <entry><type>boolean</type></entry> + <entry> + Sync a file or directory + </entry> + </row> "Flush to disk" looks better than "sync" here. +/* ------------------------------------ + * pg_file_sync + * + * We REVOKE EXECUTE on the function from PUBLIC. + * Users can then grant access to it based on their policies. + */ I think that pg_write_server_files should be allowed to call that function by default.
