Greg Stark wrote:
Actually before we get there could someone who demonstrated the
speedup verify that this patch still gets that same speedup?
Let's step back a second and get to the bottom of why some people are
seeing this and others aren't. The original report here suggested this
was a
On Fri, Jan 29, 2010 at 1:56 PM, Greg Stark wrote:
> On Tue, Jan 19, 2010 at 3:25 PM, Tom Lane wrote:
>> That function *seriously* needs documentation, in particular the fact
>> that it's a no-op on machines without the right kernel call. The name
>> you've chosen is very bad for those semantics
On Tue, Feb 2, 2010 at 12:50 PM, Tom Lane wrote:
> Andres Freund writes:
>> On Tuesday 02 February 2010 18:36:12 Robert Haas wrote:
>>> I took a look at this patch today and I agree with Tom that
>>> pg_fsync_start() is a very confusing name. I don't know what the
>>> right name is, but this doe
On Tue, Feb 2, 2010 at 1:34 PM, Andres Freund wrote:
> For now it could - but it very well might be converted to sync_file_range or
> similar, which would have different "sideeffects".
>
> As the potential code duplication is rather small I would prefer to describe
> the prime effect not the sidee
On Tue, Feb 2, 2010 at 2:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> Hmm, in that case, I think the problem is that this function has no
>> comment explaining its intended charter.
>
> That's certainly a big problem, but a comment won't fix the fact that
> the name is misleading. We need bot
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas wrote:
> I think you're probably right, but it's not clear what the new name
> should be until we have a comment explaining what the function is
> responsible for.
So I wrote some comments but wasn't going to repost the patch with the
unchanged name wit
On 02/03/10 12:53, Greg Stark wrote:
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas wrote:
I think you're probably right, but it's not clear what the new name
should be until we have a comment explaining what the function is
responsible for.
So I wrote some comments but wasn't going to repost th
On Wed, Feb 3, 2010 at 6:53 AM, Greg Stark wrote:
> On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas wrote:
>> I think you're probably right, but it's not clear what the new name
>> should be until we have a comment explaining what the function is
>> responsible for.
>
> So I wrote some comments but w
On 02/03/10 14:42, Robert Haas wrote:
On Wed, Feb 3, 2010 at 6:53 AM, Greg Stark wrote:
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas wrote:
I think you're probably right, but it's not clear what the new name
should be until we have a comment explaining what the function is
responsible for.
S
Andres Freund wrote:
On 02/03/10 14:42, Robert Haas wrote:
Well, maybe we should start with a discussion of what kernel calls
you're aware of on different platforms and then we could try to put an
API around it.
In linux there is sync_file_range. On newer Posixish systems one can
emulate that w
On Sat, Feb 6, 2010 at 7:03 AM, Andres Freund wrote:
> On Saturday 06 February 2010 06:03:30 Greg Smith wrote:
>> Andres Freund wrote:
>> > On 02/03/10 14:42, Robert Haas wrote:
>> >> Well, maybe we should start with a discussion of what kernel calls
>> >> you're aware of on different platforms an
Robert Haas wrote:
Well it seems that what we're trying to implement is more like
it_would_be_nice_if_you_would_start_syncing_this_file_range_but_its_ok_if_you_dont(),
so maybe that would work.
Anyway, is there something that we can agree on and get committed here
for 9.0, or should we postpone
On Sun, Feb 7, 2010 at 11:24 AM, Tom Lane wrote:
> Greg Smith writes:
>> This is turning into yet another one of those situations where something
>> simple and useful is being killed by trying to generalize it way more
>> than it needs to be, given its current goals and its lack of external
>> in
Andres Freund escribió:
> I personally think the fsync on the directory should be added to the stable
> branches - other opinions?
> If wanted I can prepare patches for that.
Yeah, it seems there are two patches here -- one is the addition of
fsync_fname() and the other is the fsync_prepare stuf
On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
wrote:
> Andres Freund escribió:
>> I personally think the fsync on the directory should be added to the stable
>> branches - other opinions?
>> If wanted I can prepare patches for that.
>
> Yeah, it seems there are two patches here -- one is the add
On Mon, Feb 8, 2010 at 4:53 AM, Robert Haas wrote:
> On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
>> Yeah, it seems there are two patches here -- one is the addition of
>> fsync_fname() and the other is the fsync_prepare stuff.
Sorry, I'm just catching up on my mail from FOSDEM this past weeke
16 matches
Mail list logo
