On Sun, Sep 24, 2006 at 12:26:55AM -0400, Alvaro Herrera wrote:
> Joshua D. Drake wrote:
> > Tom Lane wrote:
>
> > >I asked around inside Red Hat but haven't gotten any responses yet ...
> > >seeing that it's a rather old Suse kernel, I can understand that RH's
> > >kernel hackers might not be too
Joshua D. Drake wrote:
> Tom Lane wrote:
> >I asked around inside Red Hat but haven't gotten any responses yet ...
> >seeing that it's a rather old Suse kernel, I can understand that RH's
> >kernel hackers might not be too excited about investigating. (Alan Cox,
> >for one, has got other things t
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
The check looks good - are we chasing up the Linux kernel (or Suse) guys
to get the bug investigated?
I asked around inside Red Hat but haven't gotten any responses yet ...
seeing that it's a rather old Suse kernel, I can understand tha
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> The check looks good - are we chasing up the Linux kernel (or Suse) guys
> to get the bug investigated?
I asked around inside Red Hat but haven't gotten any responses yet ...
seeing that it's a rather old Suse kernel, I can understand that RH's
kernel h
Tom Lane wrote:
So ReadBuffer without hesitation zeroes out the page of data we just
filled, and returns it for re-filling. There went some tuples :-(
Although this is clearly Not Our Bug, it's annoying that ReadBuffer
falls into the trap so easily instead of complaining. I'm still
disincline
Some off-list investigation of Dan Kavan's data loss problem,
http://archives.postgresql.org/pgsql-admin/2006-09/msg00092.php
has led to the conclusion that it seems to be a kernel bug.
The smoking gun is this strace excerpt:
> lseek(10, 0, SEEK_END) = 913072128
> write(10, "\0\0\
