On 02/14/2010 03:49 PM, Andres Freund wrote:
On Sunday 14 February 2010 21:41:02 Mark Mielke wrote:
The widely reported problems, though, did not tend to be a problem with
directory changes written too late - but directory changes being written
too early. That is, the directory change is wri
On Sun, Feb 14, 2010 at 8:57 PM, Robert Haas wrote:
> On a pragmatic note, if this does turn out to be a problem, it's a
> bug: and we can and do fix bugs whenever we discover them. But the
> other part of this patch - to speed up createdb - is a feature - and
> we are very rapidly running out of
On Sunday 14 February 2010 21:57:08 Robert Haas wrote:
> On Sun, Feb 14, 2010 at 10:31 AM, Greg Stark wrote:
> > On Sun, Feb 14, 2010 at 2:03 PM, Greg Stark wrote:
> >> On Fri, Feb 12, 2010 at 3:49 PM, Robert Haas
wrote:
> >>> Greg Stark, have you managed to get your access issues sorted out?
On Sun, Feb 14, 2010 at 10:31 AM, Greg Stark wrote:
> On Sun, Feb 14, 2010 at 2:03 PM, Greg Stark wrote:
>> On Fri, Feb 12, 2010 at 3:49 PM, Robert Haas wrote:
>>> Greg Stark, have you managed to get your access issues sorted out? If
>>
>> Yep, will look at this today.
>
> So I think we have a
On Sunday 14 February 2010 21:41:02 Mark Mielke wrote:
> On 02/14/2010 03:24 PM, Florian Weimer wrote:
> > * Tom Lane:
> >>> Which options would that be? I am not aware that there any for any of
> >>> the recent linux filesystems.
> >>
> >> Shouldn't journaling of metadata be sufficient?
> >
> >
On 02/14/2010 03:24 PM, Florian Weimer wrote:
* Tom Lane:
Which options would that be? I am not aware that there any for any of the
recent linux filesystems.
Shouldn't journaling of metadata be sufficient?
You also need to enforce ordering between the directory update and the
* Tom Lane:
>> Which options would that be? I am not aware that there any for any of the
>> recent linux filesystems.
>
> Shouldn't journaling of metadata be sufficient?
You also need to enforce ordering between the directory update and the
file update. The file metadata is flushed with fsync()
Andres Freund writes:
> On Sunday 14 February 2010 18:11:39 Tom Lane wrote:
>> It seems to me that we're talking about a huge hit in both code
>> complexity and performance to deal with a problem that doesn't actually
>> occur in the field; and which furthermore is trivially solved on any
>> moder
On Sunday 14 February 2010 18:11:39 Tom Lane wrote:
> Greg Stark writes:
> > So I think we have a bigger problem than just copydir.c. It seems to
> > me we should be fsyncing the table space data directories on every
> > checkpoint.
>
> Is there any evidence that anyone anywhere has ever lost dat
Greg Stark writes:
> So I think we have a bigger problem than just copydir.c. It seems to
> me we should be fsyncing the table space data directories on every
> checkpoint.
Is there any evidence that anyone anywhere has ever lost data because
of a lack of directory fsyncs? I sure don't recall an
On Sun, Feb 14, 2010 at 2:03 PM, Greg Stark wrote:
> On Fri, Feb 12, 2010 at 3:49 PM, Robert Haas wrote:
>> Greg Stark, have you managed to get your access issues sorted out? If
>
> Yep, will look at this today.
So I think we have a bigger problem than just copydir.c. It seems to
me we should b
On Fri, Feb 12, 2010 at 3:49 PM, Robert Haas wrote:
> Greg Stark, have you managed to get your access issues sorted out? If
Yep, will look at this today.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
On Wed, Feb 10, 2010 at 9:27 PM, Andres Freund wrote:
> On Monday 08 February 2010 05:53:23 Robert Haas wrote:
>> 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 branc
On Monday 08 February 2010 05:53:23 Robert Haas wrote:
> 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
On Monday 08 February 2010 19:34:01 Greg Stark wrote:
> 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.
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
On Monday 08 February 2010 05:53:23 Robert Haas wrote:
> 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
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
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 Sunday 07 February 2010 19:27:02 Andres Freund wrote:
> On Sunday 07 February 2010 19:23:10 Robert Haas wrote:
> > 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
On Sunday 07 February 2010 19:23:10 Robert Haas wrote:
> 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 ne
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
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
> interfaces. There's no catversion bump or API breakage
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 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
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 and then we could try to put an
> >> API around it.
> >
> > I
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 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
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 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 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 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
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 both a comment and a name change.
re
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 Tuesday 02 February 2010 20:06:32 Robert Haas wrote:
> 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 rathe
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 Tuesday 02 February 2010 19:14:40 Robert Haas wrote:
> 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 conf
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 Tuesday 02 February 2010 18:36:12 Robert Haas wrote:
> 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
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 doesn't fsync so I don't think it shuld have
>> fsync in th
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 Tuesday 19 January 2010 15:57:14 Greg Stark wrote:
> On Tue, Jan 19, 2010 at 2:52 PM, Greg Stark wrote:
> > Barring any objections shall I commit it like this?
>
> Actually before we get there could someone who demonstrated the
> speedup verify that this patch still gets that same speedup?
At
Greg Stark writes:
> 1) moved the posix_fadvise call to a new fd.c function
> pg_fsync_start(fd,offset,nbytes) which initiates an fsync without
> waiting on it. Currently it's only implemented with
> posix_fadvise(DONT_NEED) but I want to look into using sync_file_range
> in the future -- it looks
On Tuesday 19 January 2010 15:52:25 Greg Stark wrote:
> On Mon, Jan 18, 2010 at 4:35 PM, Greg Stark wrote:
> > Looking at this patch for the commitfest I have a few questions.
>
> So I've touched this patch up a bit:
>
> 1) moved the posix_fadvise call to a new fd.c function
> pg_fsync_start(fd,
On Tuesday 29 December 2009 01:27:29 Greg Stark wrote:
> On Mon, Dec 28, 2009 at 10:54 PM, Andres Freund wrote:
> > fsync everything in that pass.
> > Including the directory - which was not done before and actually might be
> > necessary in some cases.
>
> Er. Yes. At least on ext4 this is prett
45 matches
Mail list logo
