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

Re: Debugging deadlocks

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Guy Rouillier <guyr(at)masergy(dot)com>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>,Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Debugging deadlocks
Date: 2005-04-01 01:31:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
On Thu, Mar 31, 2005 at 06:54:31PM -0600, Guy Rouillier wrote:
> Alvaro Herrera wrote:
> > 
> > Now this can't be applied right away because it's easy to run "out of
> > memory" (shared memory for the lock table).  Say, a delete or update
> > that touches 10000 tuples does not work.  I'm currently working on a
> > proposal to allow the lock table to spill to disk ...   
> While not always true, in many cases the cardinality of the referenced
> (parent) table is small compared to that of the referencing (child)
> table.  Does locking require a separate lock record for each tuple in
> the child table, or just one for each tuple in the parent table with a
> reference count?

Just one.  (LOCALLOCK, which is private to each backend, stores how many
times we hold a lock.)

I just realized we not only need to be able to spill LOCK struct to
disk, but also PROCLOCK ... am I right?

Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
La web junta la gente porque no importa que clase de mutante sexual seas,
tienes millones de posibles parejas. Pon "buscar gente que tengan sexo con
ciervos incendiándose", y el computador dirá "especifique el tipo de ciervo"
(Jason Alexander)

In response to


pgsql-hackers by date

Next:From: Qingqing ZhouDate: 2005-04-01 01:50:49
Subject: Re: [ADMIN] Excessive growth of pg_attribute and other system tables
Previous:From: Guy RouillierDate: 2005-04-01 00:54:31
Subject: Re: Debugging deadlocks

pgsql-general by date

Next:From: Joseph ShraibmanDate: 2005-04-01 01:57:17
Subject: table permissions
Previous:From: Dann CorbitDate: 2005-04-01 00:54:32
Subject: Re: your thoughts on a crazy idea please

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