On Tue, Sep 13, 2011 at 10:32:01AM -0400, Aidan Van Dyk wrote:
On Tue, Sep 13, 2011 at 10:14 AM, Florian Pflug f...@phlo.org wrote:
Personally, I'ld think that's ripe for bugs. If the contract is that
ret != amount is the error case, then don't return -1 for an error
*sometimes*.
[CC'ing to the list again - I assume you omitted pgsql-hackers from the
recipient list by accident]
On Sep13, 2011, at 03:00 , George Barnett wrote:
On 12/09/2011, at 11:39 PM, Florian Pflug wrote:
Also, non-interruptible IO primitives are by no means right. At best,
they're
a compromise
On Sep13, 2011, at 13:07 , Florian Pflug wrote:
Here's my suggested implementation for pg_write_nointr. pg_read_nointr should
be similar
(but obviously without the ENOSPC handling)
wrong pg_write_nointr implementation snipped
Sorry for the self-reply. I realized only after hitting send
On Tue, Sep 13, 2011 at 01:30:34PM +0200, Florian Pflug wrote:
On Sep13, 2011, at 13:07 , Florian Pflug wrote:
Here's my suggested implementation for pg_write_nointr. pg_read_nointr
should be similar
(but obviously without the ENOSPC handling)
wrong pg_write_nointr implementation
On Sep13, 2011, at 14:58 , k...@rice.edu wrote:
It will be interesting to see if there are any performance ramifications to
this new write function.
What would those be? For non-interruptible reads and writes, the overhead
comes down to an additional function call (if we don't make
On Tue, Sep 13, 2011 at 03:02:57PM +0200, Florian Pflug wrote:
On Sep13, 2011, at 14:58 , k...@rice.edu wrote:
It will be interesting to see if there are any performance ramifications to
this new write function.
What would those be? For non-interruptible reads and writes, the overhead
On Tue, Sep 13, 2011 at 7:30 AM, Florian Pflug f...@phlo.org wrote:
Sorry for the self-reply. I realized only after hitting send that I
got the ENOSPC handling wrong again - we probably ought to check for
ENOSPC as well as ret == 0. Also, it seems preferable to return the
number of bytes
On Sep13, 2011, at 15:05 , Aidan Van Dyk wrote:
On Tue, Sep 13, 2011 at 7:30 AM, Florian Pflug f...@phlo.org wrote:
Sorry for the self-reply. I realized only after hitting send that I
got the ENOSPC handling wrong again - we probably ought to check for
ENOSPC as well as ret == 0. Also, it
Florian Pflug f...@phlo.org writes:
On Sep13, 2011, at 15:05 , Aidan Van Dyk wrote:
Personally, I'ld think that's ripe for bugs. If the contract is that
ret != amount is the error case, then don't return -1 for an error
*sometimes*.
Hm, but isn't that how write() works also?
Yeah. It's
On Tue, Sep 13, 2011 at 10:14 AM, Florian Pflug f...@phlo.org wrote:
Personally, I'ld think that's ripe for bugs. If the contract is that
ret != amount is the error case, then don't return -1 for an error
*sometimes*.
Hm, but isn't that how write() works also? AFAIK (non-interruptible)
On Sep13, 2011, at 16:25 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On Sep13, 2011, at 15:05 , Aidan Van Dyk wrote:
Personally, I'ld think that's ripe for bugs. If the contract is that
ret != amount is the error case, then don't return -1 for an error
*sometimes*.
Hm, but
On Sep12, 2011, at 06:30 , George Barnett wrote:
On 10/09/2011, at 1:30 AM, Bernd Helmle wrote:
--On 9. September 2011 10:27:22 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
On the whole I think you'd be better off lobbying your NFS implementors
to provide something closer to the behavior of
On 12/09/2011, at 3:59 PM, Florian Pflug wrote:
If you really meant to say intr there (and not nointr) then that probably
explains the partial writes.
Still, I agree with Noah and Kevin that we ought to deal more gracefully with
this, i.e. resubmit after a partial read() or write().
On mån, 2011-09-12 at 16:46 +1000, George Barnett wrote:
On 12/09/2011, at 3:59 PM, Florian Pflug wrote:
If you really meant to say intr there (and not nointr) then that
probably explains the partial writes.
Still, I agree with Noah and Kevin that we ought to deal more gracefully
On Mon, Sep 12, 2011 at 04:46:53PM +1000, George Barnett wrote:
On 12/09/2011, at 3:59 PM, Florian Pflug wrote:
If you really meant to say intr there (and not nointr) then that
probably explains the partial writes.
Still, I agree with Noah and Kevin that we ought to deal more
On Sep12, 2011, at 14:54 , Peter Eisentraut wrote:
On mån, 2011-09-12 at 16:46 +1000, George Barnett wrote:
On 12/09/2011, at 3:59 PM, Florian Pflug wrote:
Still, I agree with Noah and Kevin that we ought to deal more gracefully
with this, i.e. resubmit after a partial read() or write().
On Sep12, 2011, at 14:54 , k...@rice.edu wrote:
Many, many, many other software packages expect I/O usage to be the same on
an NFS volume and a local disk volume, including Oracle. Coding every
application,
or more likely mis-coding, to handle this gives every application another
chance
to
On Mon, Sep 12, 2011 at 9:39 AM, Florian Pflug f...@phlo.org wrote:
Really, it's not *that* hard to put a retry loop around read and write.
+1. I don't see what we're gaining by digging in our heels on this
one. Retry loops around read() and write() are pretty routine, and I
wouldn't like to
On 10/09/2011, at 1:30 AM, Bernd Helmle wrote:
--On 9. September 2011 10:27:22 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
On the whole I think you'd be better off lobbying your NFS implementors
to provide something closer to the behavior of every other filesystem on
the planet. Or checking
On 9 September 2011 01:04, George Barnett gbarn...@atlassian.com wrote:
After looking through the code I found that when postgres calls write() it
doesn't retry. In order to address the issue with the PANIC in the WAL
writer I set the sync method to o_sync which solved the issue in that part
On fre, 2011-09-09 at 10:04 +1000, George Barnett wrote:
After looking through the code I found that when postgres calls
write() it doesn't retry. In order to address the issue with the
PANIC in the WAL writer I set the sync method to o_sync which solved
the issue in that part of the code,
George Barnett gbarn...@atlassian.com writes:
[ patch to retry writes on NFS ]
I'm having a hard time getting excited about this idea, because IMO
NFS is insufficiently reliable to run a database on, and no patch like
this can fix that. However, some concrete points:
1. If writes need to be
--On 9. September 2011 10:27:22 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
On the whole I think you'd be better off lobbying your NFS implementors
to provide something closer to the behavior of every other filesystem on
the planet. Or checking to see if you need to adjust your NFS
On Fri, Sep 09, 2011 at 10:27:22AM -0400, Tom Lane wrote:
George Barnett gbarn...@atlassian.com writes:
[ patch to retry writes on NFS ]
I'm having a hard time getting excited about this idea, because IMO
NFS is insufficiently reliable to run a database on, and no patch like
this can fix
Noah Misch n...@leadboat.com wrote:
We shouldn't complain when a kernel provides a conforming write(),
even if it appears that the kernel achieved little by using some
freedom afforded it.
I remember we had some compiler warnings in the logging area because
we were making the assumption
Tom Lane wrote:
George Barnett gbarn...@atlassian.com writes:
[ patch to retry writes on NFS ]
I'm having a hard time getting excited about this idea, because IMO
NFS is insufficiently reliable to run a database on, and no patch like
this can fix that. However, some concrete points:
1.
George,
I'm quoting you here because in the version of your email which got
posted to the list your whole explanation got put below the patch text,
making it hard to find the justification for the patch. Follows:
I run a number of postgresql installations on NFS and on the whole I find
this
27 matches
Mail list logo
