| From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Deadlock with tsearch2 index ... |
| Date: | 2005-05-31 22:57:22 |
| Message-ID: | 20050531195525.M933@ganymede.hub.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 31 May 2005, Tom Lane wrote:
> (2) we acquire and release the index lock for each *tuple* rather than
> each statement. Then client2 doesn't hold the index lock while it's
> waiting for the row lock to clear.
>
> Neither of these cures sounds attractive :-(. I think #1 would probably
> do as much to create deadlock cases as to prevent them. #2 would avoid
> the deadlock but the performance cost would be high.
But ... this wouldn't affect SELECT operations, would it? And only GiST
related operations? Would the performance loss be noticeable? And, would
the performance cost not be worth getting rid of the deadlocks, until the
concurrency issues can be properly dealt with?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2005-05-31 23:01:43 | NOLOGGING option, or ? |
| Previous Message | Christopher Browne | 2005-05-31 22:41:55 | Re: Consumer-grade vs enterprise-grade disk drives |