On 2020/01/24 17:08, Fujii Masao wrote:
On 2020/01/24 16:56, Julien Rouhaud wrote:
On Fri, Jan 24, 2020 at 8:20 AM Fujii Masao
wrote:
On 2020/01/24 15:38, Arthur Zakirov wrote:
On 2020/01/24 14:56, Michael Paquier wrote:
On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
On 2020/01/24 16:56, Julien Rouhaud wrote:
On Fri, Jan 24, 2020 at 8:20 AM Fujii Masao wrote:
On 2020/01/24 15:38, Arthur Zakirov wrote:
On 2020/01/24 14:56, Michael Paquier wrote:
On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
It is compiled and passes the tests. There
On Fri, Jan 24, 2020 at 8:20 AM Fujii Masao wrote:
>
> On 2020/01/24 15:38, Arthur Zakirov wrote:
> > On 2020/01/24 14:56, Michael Paquier wrote:
> >> On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
> >>> It is compiled and passes the tests. There is the documentation and
> >>> it
On 2020/01/24 15:38, Arthur Zakirov wrote:
On 2020/01/24 14:56, Michael Paquier wrote:
On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
It is compiled and passes the tests. There is the documentation and
it is
built too without an error.
It seems that consensus about the retu
On 2020/01/24 14:56, Michael Paquier wrote:
On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
It is compiled and passes the tests. There is the documentation and it is
built too without an error.
It seems that consensus about the returned type was reached and I marked the
patch as
On Fri, Jan 24, 2020 at 6:56 AM Michael Paquier wrote:
>
> On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
> > It is compiled and passes the tests. There is the documentation and it is
> > built too without an error.
> >
> > It seems that consensus about the returned type was reach
On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
> It is compiled and passes the tests. There is the documentation and it is
> built too without an error.
>
> It seems that consensus about the returned type was reached and I marked the
> patch as "Ready for Commiter".
+ fsync
On 2020/01/17 16:05, Fujii Masao wrote:
On 2020/01/17 13:36, Michael Paquier wrote:
Yeah, that should be either ERROR and return a void result, or issue a
WARNING/ERROR (depending on the code path, maybe PANIC?) with a
boolean status returned if there is a WARNING. Mixing both concepts
with an
On 2020/01/13 22:46, Michael Paquier 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
On 2020/01/17 13:36, Michael Paquier wrote:
On Thu, Jan 16, 2020 at 09:51:24AM -0500, Robert Haas wrote:
On Tue, Jan 14, 2020 at 10:08 AM Atsushi Torikoshi wrote:
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 16, 2020 at 09:51:24AM -0500, Robert Haas wrote:
> On Tue, Jan 14, 2020 at 10:08 AM Atsushi Torikoshi wrote:
>> fails we can get error messages. So it seems straightforward for me to
>> 'return true on success and emit an ERROR otherwise'.
>
> I agree with reporting errors using ERRO
On Tue, Jan 14, 2020 at 10:08 AM Atsushi Torikoshi wrote:
> fails we can get error messages. So it seems straightforward for me to
> 'return true on success and emit an ERROR otherwise'.
I agree with reporting errors using ERROR, but it seems to me that we
ought to then make the function return
On Wed, Jan 15, 2020 at 1:49 Julien Rouhaud :
> Actually, pg_write_server_files has enough privileges to execute those
> functions anywhere on the FS as far as C code is concerned, provided
> that the user running postgres daemon is allowed to (see
> convert_and_check_filename), but won't be allow
Le mar. 14 janv. 2020 à 22:57, Stephen Frost a écrit :
> Greetings,
>
> * Julien Rouhaud (rjuju...@gmail.com) wrote:
> > On Fri, Jan 10, 2020 at 10:50 AM Fujii Masao
> wrote:
> > > On Thu, Jan 9, 2020 at 10:39 PM Julien Rouhaud
> wrote:
> > > > I think that pg_write_server_files should be allow
Greetings,
* Julien Rouhaud (rjuju...@gmail.com) wrote:
> On Fri, Jan 10, 2020 at 10:50 AM Fujii Masao wrote:
> > On Thu, Jan 9, 2020 at 10:39 PM Julien Rouhaud wrote:
> > > I think that pg_write_server_files should be allowed to call that
> > > function by default.
> >
> > But pg_write_server_f
On Tue, Jan 14, 2020 at 4:08 PM Atsushi Torikoshi wrote:
>
> > On Sut, Jan 11, 2020 at 2:12 Fujii Masao :
> > > 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.
Hello,
> On Sut, Jan 11, 2020 at 2:12 Fujii Masao :
> 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.
On Tue, Jan 14, 2020 at 7:18 AM Michael Paquier wrote:
>
> On Mon, Jan 13, 2020 at 03:39:32PM +0100, Julien Rouhaud wrote:
> > 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?
On Mon, Jan 13, 2020 at 03:39:32PM +0100, Julien Rouhaud wrote:
> 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?
Are you mistaking security with durability here? By default, th
On Mon, Jan 13, 2020 at 2:46 PM Michael Paquier 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 e
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 thi
Hello,
On Sat, Jan 11, 2020 at 2:12 AM Fujii Masao wrote:
> > +
> > + pg_file_sync fsyncs the specified file or directory
> > + named by filename. Returns true on success,
> > + an error is thrown otherwise (e.g., the specified file is not present).
> > +
> > What's the point of having a fu
On Fri, Jan 10, 2020 at 8:16 PM Michael Paquier wrote:
>
> On Fri, Jan 10, 2020 at 06:50:12PM +0900, Fujii Masao wrote:
> > I changed the doc that way. Thanks for the review!
Thanks for the review!
> +
> + pg_file_sync fsyncs the specified file or directory
> + named by filename. Returns tru
On Fri, Jan 10, 2020 at 10:50 AM Fujii Masao wrote:
>
> On Thu, Jan 9, 2020 at 10:39 PM Julien Rouhaud 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
On Fri, Jan 10, 2020 at 06:50:12PM +0900, Fujii Masao wrote:
> I changed the doc that way. Thanks for the review!
+
+ pg_file_sync fsyncs the specified file or directory
+ named by filename. Returns true on success,
+ an error is thrown otherwise (e.g., the specified file is not present).
+
On Thu, Jan 9, 2020 at 10:39 PM Julien Rouhaud wrote:
>
> On Thu, Jan 9, 2020 at 7:31 AM Fujii Masao wrote:
> >
> > On Mon, Jan 6, 2020 at 3:42 PM Michael Paquier 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
Julien Rouhaud writes:
> On Thu, Jan 9, 2020 at 6:16 PM Stephen Frost wrote:
>> Why would you expect that when it isn't the case for the filesystem
>> itself..?
> Just a usual habit with durable property.
I tend to agree with Stephen on this, mainly because the point of
these adminpack function
On Thu, Jan 9, 2020 at 6:16 PM Stephen Frost wrote:
>
> Greetings,
>
> * Julien Rouhaud (rjuju...@gmail.com) wrote:
> > On Thu, Jan 9, 2020 at 7:43 AM Fujii Masao wrote:
> > > On Wed, Dec 25, 2019 at 11:11 PM Julien Rouhaud
> > > wrote:
> > > > On Wed, Dec 25, 2019 at 2:01 PM Fujii Masao
> >
Greetings,
* Julien Rouhaud (rjuju...@gmail.com) wrote:
> On Thu, Jan 9, 2020 at 7:43 AM Fujii Masao wrote:
> > On Wed, Dec 25, 2019 at 11:11 PM Julien Rouhaud wrote:
> > > On Wed, Dec 25, 2019 at 2:01 PM Fujii Masao wrote:
> > > > I'd like to propose to add pg_file_sync() function into
> > >
On Thu, Jan 9, 2020 at 7:31 AM Fujii Masao wrote:
>
> On Mon, Jan 6, 2020 at 3:42 PM Michael Paquier 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: c
On Thu, Jan 9, 2020 at 7:43 AM Fujii Masao wrote:
>
> On Wed, Dec 25, 2019 at 11:11 PM Julien Rouhaud wrote:
> >
> > On Wed, Dec 25, 2019 at 2:01 PM Fujii Masao wrote:
> > >
> > > Hi,
> > >
> > > I'd like to propose to add pg_file_sync() function into contrib/adminpack.
> > > This function fsync
On Wed, Dec 25, 2019 at 11:11 PM Julien Rouhaud wrote:
>
> On Wed, Dec 25, 2019 at 2:01 PM Fujii Masao wrote:
> >
> > Hi,
> >
> > I'd like to propose to add pg_file_sync() function into contrib/adminpack.
> > This function fsyncs the specified file or directory named by its argument.
> > IMO this
On Mon, Jan 6, 2020 at 3:42 PM Michael Paquier 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
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
Hello,
On 2019/12/25 23:12, Julien Rouhaud wrote:
On Wed, Dec 25, 2019 at 2:01 PM Fujii Masao wrote:
Hi,
I'd like to propose to add pg_file_sync() function into contrib/adminpack.
This function fsyncs the specified file or directory named by its argument.
IMO this is useful, for example, whe
On Wed, Dec 25, 2019 at 2:01 PM Fujii Masao wrote:
>
> Hi,
>
> I'd like to propose to add pg_file_sync() function into contrib/adminpack.
> This function fsyncs the specified file or directory named by its argument.
> IMO this is useful, for example, when you want to fsync the file that
> pg_file_
Hi,
I'd like to propose to add pg_file_sync() function into contrib/adminpack.
This function fsyncs the specified file or directory named by its argument.
IMO this is useful, for example, when you want to fsync the file that
pg_file_write() writes out or that COPY TO exports the data into,
for dur
37 matches
Mail list logo
