From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, current-users(at)netbsd(dot)org |
Subject: | Re: PostgreSQL, NetBSD and NFS |
Date: | 2003-02-05 16:49:56 |
Message-ID: | 26882.1044463796@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"D'Arcy J.M. Cain" <darcy(at)druid(dot)net> writes:
> Hmm. This time it passed that point but this happened:
> COPY "certificate" FROM stdin;
> NOTICE: copy: line 253677, bt_insertonpg[certificate_pkey]: parent page
> unfound - fixing branch
> ERROR: copy: line 253677, bt_fixlevel[certificate_pkey]: invalid item
> order(1) (need to recreate index)
Hoo boy. I was already suspecting data corruption in the index, and
this looks like more of the same. My thoughts are definitely straying
in the direction of "the NFS server is dropping bits, somehow".
Both this and the (admittedly unproven) bt_moveright loop suggest
corrupted values in the cross-page links that exist at the very end of
each btree index page. I wonder if it is possible that, every so often,
you are losing just the last few bytes of an NFS transfer?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | wade | 2003-02-05 16:50:01 | Re: POSIX regex performance bug in 7.3 Vs. 7.2 |
Previous Message | Bruno Wolff III | 2003-02-05 16:45:57 | Re: PGP signing releases |