Andres Freund writes:
> On 2016-04-13 18:09:18 -0400, Tom Lane wrote:
>> BTW, I just noticed another issue here, which is that FileWriteback
>> and the corresponding smgr routines are declared with bogusly narrow
>> "amount" arguments --- eg, it's silly that FileWriteback only takes
>> an int amou
On 2016-04-13 18:09:18 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-04-13 17:44:41 -0400, Tom Lane wrote:
> >> fd.c tracks seek position for open files. I'm not sure that that
> >> function can get called with amount == 0, but if it did, the caller
> >> would certainly not be expect
Andres Freund writes:
> On 2016-04-13 17:44:41 -0400, Tom Lane wrote:
>> fd.c tracks seek position for open files. I'm not sure that that
>> function can get called with amount == 0, but if it did, the caller
>> would certainly not be expecting the file position to change.
> Ok, fair enough. (A
On 2016-04-13 17:44:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'm not entirely sure what
>
> > + /*
> > +* Caution: do not call pg_flush_data with amount = 0, it could trash
> > the
> > +* file's seek position.
> > +*/
> > + if (amount <= 0)
> > + return;
> > +
Andres Freund writes:
> I'm not entirely sure what
> + /*
> +* Caution: do not call pg_flush_data with amount = 0, it could trash the
> +* file's seek position.
> +*/
> + if (amount <= 0)
> + return;
> +
> is about?
fd.c tracks seek position for open files. I'm not sure t
On 2016-04-13 17:21:01 -0400, Tom Lane wrote:
> I concluded that sharing the code would be more trouble than it's worth,
> because initdb.c's version of this is in fact not broken: it was never
> taught about mmap, and it doesn't need to be IMO, because it's not that
> performance-critical.
Agreed
I wrote:
> Michael Paquier writes:
>> A similar change seems to be needed in initdb.c's pre_sync_fname.
> Hmm, do we need to move this logic into src/common?
I concluded that sharing the code would be more trouble than it's worth,
because initdb.c's version of this is in fact not broken: it was
Michael Paquier writes:
> On Mon, Mar 21, 2016 at 9:09 PM, Stas Kelvich
> wrote:
>> On 21 Mar 2016, at 14:53, Andres Freund wrote:
>>> I think we still need to fix the mmap() implementation to support the
>>> offset = 0, nbytes = 0 case (via fseek(SEEK_END).
>> It is already in this diff. Iâ
On Mon, Mar 21, 2016 at 9:09 PM, Stas Kelvich wrote:
> On 21 Mar 2016, at 14:53, Andres Freund wrote:
>> Hm. I think we should rather just skip calling pg_flush_data in the
>> directory case, that very likely isn't beneficial on any OS.
>
> Seems reasonable, changed.
>
>> I think we still need to
On Mon, Mar 21, 2016 at 03:09:56PM +0300, Stas Kelvich wrote:
> On 21 Mar 2016, at 14:53, Andres Freund wrote:
> > Hm. I think we should rather just skip calling pg_flush_data in the
> > directory case, that very likely isn't beneficial on any OS.
>
> Seems reasonable, changed.
>
> > I think we
On 21 Mar 2016, at 14:53, Andres Freund wrote:
> Hm. I think we should rather just skip calling pg_flush_data in the
> directory case, that very likely isn't beneficial on any OS.
Seems reasonable, changed.
> I think we still need to fix the mmap() implementation to support the
> offset = 0, nby
On 2016-03-21 14:46:09 +0300, Stas Kelvich wrote:
>
> > On 18 Mar 2016, at 14:45, Stas Kelvich wrote:
> >>
> >>> One possible solution for that is just fallback to pg_fdatasync in case
> >>> when offset = nbytes = 0.
> >>
> >> Hm, that's a bit heavyweight. I'd rather do an lseek(SEEK_END) to g
> On 18 Mar 2016, at 14:45, Stas Kelvich wrote:
>>
>>> One possible solution for that is just fallback to pg_fdatasync in case
>>> when offset = nbytes = 0.
>>
>> Hm, that's a bit heavyweight. I'd rather do an lseek(SEEK_END) to get
>> the file size. Could you test that?
>>
>
> It looks like
Hi
Current implementation of pg_flush_data when called with zero offset and zero
nbytes is assumed to flush all file. In osx it uses mmap with these arguments,
but according to man:
"[EINVAL] The len argument was negative or zero. Historically, the
system call would not return an
Hi,
On 2016-03-17 20:09:53 +0300, Stas Kelvich wrote:
> Current implementation of pg_flush_data when called with zero offset and zero
> nbytes is assumed to flush all file. In osx it uses mmap with these
> arguments, but according to man:
>
> "[EINVAL] The len argument was negative o
> On 17 Mar 2016, at 20:23, Andres Freund wrote:
>
>>
>> Also there are no default ifdef inside this function, is there any
>> check that will guarantee that pg_flush_data will not end up with
>> empty body on some platform?
>
> There doesn't need to be - it's purely "advisory", i.e. just an
>
16 matches
Mail list logo
