On Fri, Feb 12, 2010 at 3:49 PM, Robert Haas robertmh...@gmail.com 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:
On Sun, Feb 14, 2010 at 2:03 PM, Greg Stark gsst...@mit.edu wrote:
On Fri, Feb 12, 2010 at 3:49 PM, Robert Haas robertmh...@gmail.com 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
Greg Stark gsst...@mit.edu 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
On Sunday 14 February 2010 18:11:39 Tom Lane wrote:
Greg Stark gsst...@mit.edu 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
Andres Freund and...@anarazel.de 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
On Sun, Feb 14, 2010 at 10:31 AM, Greg Stark gsst...@mit.edu wrote:
On Sun, Feb 14, 2010 at 2:03 PM, Greg Stark gsst...@mit.edu wrote:
On Fri, Feb 12, 2010 at 3:49 PM, Robert Haas robertmh...@gmail.com wrote:
Greg Stark, have you managed to get your access issues sorted out? If
Yep, will
On Sunday 14 February 2010 21:57:08 Robert Haas wrote:
On Sun, Feb 14, 2010 at 10:31 AM, Greg Stark gsst...@mit.edu wrote:
On Sun, Feb 14, 2010 at 2:03 PM, Greg Stark gsst...@mit.edu wrote:
On Fri, Feb 12, 2010 at 3:49 PM, Robert Haas robertmh...@gmail.com
wrote:
Greg Stark, have you
On Sun, Feb 14, 2010 at 8:57 PM, Robert Haas robertmh...@gmail.com 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
On Wed, Feb 10, 2010 at 9:27 PM, Andres Freund and...@anarazel.de wrote:
On Monday 08 February 2010 05:53:23 Robert Haas wrote:
On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Andres Freund escribió:
I personally think the fsync on the directory should be
On Monday 08 February 2010 05:53:23 Robert Haas wrote:
On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Mon, Feb 8, 2010 at 4:53 AM, Robert Haas robertmh...@gmail.com 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
On Monday 08 February 2010 19:34:01 Greg Stark wrote:
On Mon, Feb 8, 2010 at 4:53 AM, Robert Haas robertmh...@gmail.com 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
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
Greg Smith g...@2ndquadrant.com 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
On Sun, Feb 7, 2010 at 11:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith g...@2ndquadrant.com 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
On Sunday 07 February 2010 19:23:10 Robert Haas wrote:
On Sun, Feb 7, 2010 at 11:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith g...@2ndquadrant.com writes:
This is turning into yet another one of those situations where something
simple and useful is being killed by trying to
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 t...@sss.pgh.pa.us wrote:
Greg Smith g...@2ndquadrant.com writes:
This is turning into yet another one of those situations where
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 stuff.
On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Monday 08 February 2010 05:53:23 Robert Haas wrote:
On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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.
In linux there
On Sat, Feb 6, 2010 at 7:03 AM, Andres Freund and...@anarazel.de 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
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
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas robertmh...@gmail.com 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
On 02/03/10 12:53, Greg Stark wrote:
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haasrobertmh...@gmail.com 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
On Wed, Feb 3, 2010 at 6:53 AM, Greg Stark gsst...@mit.edu wrote:
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas robertmh...@gmail.com 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
On 02/03/10 14:42, Robert Haas wrote:
On Wed, Feb 3, 2010 at 6:53 AM, Greg Starkgsst...@mit.edu wrote:
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haasrobertmh...@gmail.com 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
Andres Freund and...@anarazel.de 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
On Tuesday 02 February 2010 18:36:12 Robert Haas wrote:
On Fri, Jan 29, 2010 at 1:56 PM, Greg Stark gsst...@mit.edu wrote:
On Tue, Jan 19, 2010 at 3:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That function *seriously* needs documentation, in particular the fact
that it's a no-op on machines
On Tue, Feb 2, 2010 at 12:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de 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
On Tuesday 02 February 2010 19:14:40 Robert Haas wrote:
On Tue, Feb 2, 2010 at 12:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de 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
On Tue, Feb 2, 2010 at 1:34 PM, Andres Freund and...@anarazel.de 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
On Tuesday 02 February 2010 20:06:32 Robert Haas wrote:
On Tue, Feb 2, 2010 at 1:34 PM, Andres Freund and...@anarazel.de 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
On Fri, Jan 29, 2010 at 1:56 PM, Greg Stark gsst...@mit.edu wrote:
On Tue, Jan 19, 2010 at 3:25 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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.
On Tue, Feb 2, 2010 at 2:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Jan 19, 2010 at 3:25 PM, Tom Lane t...@sss.pgh.pa.us 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. I'd pick something
else myself.
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
On Mon, Jan 18, 2010 at 4:35 PM, Greg Stark gsst...@mit.edu 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,offset,nbytes) which initiates an fsync without
On Tue, Jan 19, 2010 at 2:52 PM, Greg Stark gsst...@mit.edu 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?
--
greg
--
Sent via pgsql-hackers mailing list
On Tuesday 19 January 2010 15:52:25 Greg Stark wrote:
On Mon, Jan 18, 2010 at 4:35 PM, Greg Stark gsst...@mit.edu 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
Greg Stark gsst...@mit.edu 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
On Tuesday 19 January 2010 15:57:14 Greg Stark wrote:
On Tue, Jan 19, 2010 at 2:52 PM, Greg Stark gsst...@mit.edu 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
Looking at this patch for the commitfest I have a few questions.
1) You said you added an fsync of the new directory -- where is that I
don't see it anywhere.
2) Why does the second pass to do the fsyncs read through fromdir to
find all the filenames. I find that odd and counterintuitive. It
On Mon, Dec 28, 2009 at 10:54 PM, Andres Freund and...@anarazel.de 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 pretty important. I wish it weren't,
but it doesn't look
On Tuesday 29 December 2009 01:27:29 Greg Stark wrote:
On Mon, Dec 28, 2009 at 10:54 PM, Andres Freund and...@anarazel.de 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
46 matches
Mail list logo
