Re: Debugging deadlocks

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

In response to

Responses

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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?