Re: Debugging deadlocks - Mailing list pgsql-general

From Tom Lane
Subject Re: Debugging deadlocks
Date
Msg-id 779.1112414556@sss.pgh.pa.us
Whole thread Raw
In response to Re: Debugging deadlocks  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Re: Debugging deadlocks  (Greg Stark <gsstark@mit.edu>)
Re: Debugging deadlocks  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List pgsql-general
Alvaro Herrera <alvherre@dcc.uchile.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

pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: plPHP in core?
Next
From: "Marc G. Fournier"
Date:
Subject: Re: [HACKERS] plPHP in core?