Re: Add pg_file_sync() to adminpack

From: Atsushi Torikoshi <atorik(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Julien Rouhaud <rjuju123(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-14 15:08:06
Message-ID: CACZ0uYGAkKeA-tsX82Ypuu1HkWem8=VeBpK0XNOD51ackKD1+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

> On Sut, Jan 11, 2020 at 2:12 Fujii Masao <masao(dot)fujii(at)gmail(dot)com>:
> 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.

+1.
As a user, I expect these adminpack functions to do similar behaviors
to the corresponding system calls.
System calls for flushing data to disk(fsync on Linux and FlushFileBuffers
on Windows) return different codes on success and failure, and when it
fails we can get error messages. So it seems straightforward for me to
'return true on success and emit an ERROR otherwise'.

> > On Thu, Jan 9, 2020 at 10:39 PM Julien Rouhaud <rjuju123(at)gmail(dot)com>
wrote:
> > >
> > > I think that pg_write_server_files should be allowed to call that
> > > function by default.
> >
> > But pg_write_server_files users are not allowed to execute
> > other functions like pg_file_write() by default. So doing that
> > change only for pg_file_sync() looks strange to me.

> Ah indeed. I'm wondering if that's an oversight of the original
> default role patch or voluntary.

It's not directly related to the patch, but as far as I read the
manual below, I expected pg_write_server_files users could execute
adminpack functions.

| Table 21.1 Default Roles
| pg_write_server_files: Allow writing to files in any location the
database can access on the server with COPY and other file-access functions.

--
Atsushi Torikoshi

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-01-14 15:10:36 Re: Unicode escapes with any backend encoding
Previous Message Daniel Verite 2020-01-14 14:53:37 Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR