From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | Paul Tillotson <pntil(at)shentel(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Debugging deadlocks |
Date: | 2005-04-02 04:02:36 |
Message-ID: | 779.1112414556@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> On Fri, Apr 01, 2005 at 10:14:07PM -0500, Paul Tillotson wrote:
>> ...
> Well, at that point you need to take a lock in order to be able to
> manage locks. Managing not to step on your own feet in that scenario
> is complex, to say the least, if not downright impossible.
I looked at Paul's first message and thought "nah, that won't work
because ... because ... hmm ... hmmm ..."
We currently store tuple locks on the same page as the tuples (ie, in
the tuple headers) and need no extra locks to do so. Certainly it
still has to have a spill mechanism, but the thought that is attractive
to me is that until you are forced to spill, you do not have to take any
system-wide lock, only a page-level lock. So it could have very good
average performance.
> Another problem with this approach is that it would be practically
> impossible for a process to release all its locks when it finishes.
There is no explicit release of tuple-level locks in the current setup.
Need it be different in Paul's idea?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2005-04-02 04:43:25 | Re: [HACKERS] plPHP in core? |
Previous Message | Bruce Momjian | 2005-04-02 03:40:46 | Re: Disk Encryption - Postgresql vs. Oracle |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2005-04-02 04:17:06 | Re: LEFT JOIN used in psql describe.c |
Previous Message | Alvaro Herrera | 2005-04-02 03:27:24 | Re: plPHP in core? |