| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | "Ross Elliott" <ross(dot)elliott(at)infoterra-global(dot)com> | 
| Cc: | "Michael Fuhr" <mike(at)fuhr(dot)org>, pgsql-bugs(at)postgresql(dot)org | 
| Subject: | Re: BUG #2631: database locking problem | 
| Date: | 2006-09-17 21:45:12 | 
| Message-ID: | 25485.1158529512@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
"Ross Elliott" <ross(dot)elliott(at)infoterra-global(dot)com> writes:
> I've been playing with this a bit more by switching to 8.1.3 with
> postgis 1.1.3 and still get the locking problem.
Well, that's dang odd.  PID 9403 seems to be the problem, because it's
got extend lock on topoarea_idx2, which is a lock that should be held
for only a *very* short time.  Apparently it's blocked on an LWLock
inside either ReadBuffer or LockBuffer --- but the LockBuffer should
certainly not block because ReadBuffer should have returned a page that
never existed until just now, and hence couldn't be locked by anyone
else.  Even more interesting, topoarea_idx2 is a plain btree, which
shouldn't be affected at all by postgis.  And none of this code has
changed much recently.
Can you attach to 9403 with a debugger and get a stack trace to confirm
exactly where it's blocked?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ross Elliott | 2006-09-17 21:55:49 | Re: BUG #2631: database locking problem | 
| Previous Message | Ross Elliott | 2006-09-17 17:11:55 | Re: BUG #2631: database locking problem |