Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-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

pgsql-hackers by date

Next:From: Greg Sabino MullaneDate: 2005-04-02 04:17:06
Subject: Re: LEFT JOIN used in psql describe.c
Previous:From: Alvaro HerreraDate: 2005-04-02 03:27:24
Subject: Re: plPHP in core?

pgsql-general by date

Next:From: Marc G. FournierDate: 2005-04-02 04:43:25
Subject: Re: [HACKERS] plPHP in core?
Previous:From: Bruce MomjianDate: 2005-04-02 03:40:46
Subject: Re: Disk Encryption - Postgresql vs. Oracle

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group