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 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*.
> >
> >
On Sep13, 2011, at 16:25 , Tom Lane wrote:
> Florian Pflug 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 i
On Tue, Sep 13, 2011 at 10:14 AM, Florian Pflug 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) write()
Florian Pflug 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 not p
On Sep13, 2011, at 15:05 , Aidan Van Dyk wrote:
> On Tue, Sep 13, 2011 at 7:30 AM, Florian Pflug 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 prefe
On Tue, Sep 13, 2011 at 7:30 AM, Florian Pflug 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 actually wri
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 overhea
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 pg_write_no
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)
> >
> >
>
> Sorry for the self-reply.
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)
>
>
Sorry for the self-reply. I realized only after hitting send that I
got the ENOSPC handling wrong again
[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 compro
On Mon, Sep 12, 2011 at 9:39 AM, Florian Pflug 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 bet this i
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
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 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
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 gr
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 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 wrote:
>>
>>> On the whole I think you'd be better off lobbying your NFS implementors
>>> to provide something closer to the behavior of every oth
On 10/09/2011, at 1:30 AM, Bernd Helmle wrote:
> --On 9. September 2011 10:27:22 -0400 Tom Lane 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 yo
Tom Lane wrote:
> George Barnett 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 nee
Noah Misch 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 that no implementa
On Fri, Sep 09, 2011 at 10:27:22AM -0400, Tom Lane wrote:
> George Barnett 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, s
--On 9. September 2011 10:27:22 -0400 Tom Lane 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
configuration, as the other res
George Barnett 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 retried, why not reads?
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,
On 9 September 2011 01:04, 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, how
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
Hi Hackers,
postgresql-writeall.patch
Description: Binary data
I run a number of postgresql installations on NFS and on the whole I find this
to be very reliable. I have however run into a few issues when there is
concurrent writes from multiple processes.
I see errors such as the following:
28 matches
Mail list logo
