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 15:12:32 |
Message-ID: | 25956.1044457952@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:
> Well, it does appear to be working but it never finishes. Here are two
> backtraces. One was taken while it was running and the other after a kill
> -9. The primary key file should have had 322846720 bytes based on the
> database that I was copying in but it only had 4603904 after running the
> restore for 12 hours. The file seems to get to a static size and just stays
> there. I am running another test to confirm that.
Hmm --- seems like it must be getting into an infinite loop, but where
and why? Here is a test plan:
1. Run it, let it reach the point where the file size stops growing.
2. Attach to process with gdb. Repeatedly do 'fin' to finish out current
function call, until the prompt doesn't come back any more. Whichever
level of function didn't finish reasonably quickly is the one that's
looping.
3. Control-C to get control back in gdb. Do 'fin' enough times to get
back to the looping function, but not the extra time to let it run.
Now, use 'next' repeatedly to see just what lines it's circling around
in, and print out the values of its local variables as it does so.
That info should move the investigation forward ...
From looking at your existing dumps I will hazard a guess that
_bt_moveright is looping ... but why? And why should that happen
only with NFS?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | D'Arcy J.M. Cain | 2003-02-05 16:40:12 | Re: PostgreSQL, NetBSD and NFS |
Previous Message | Tom Lane | 2003-02-05 14:59:01 | Re: POSIX regex performance bug in 7.3 Vs. 7.2 |