Re: [GENERAL] Debugging deadlocks - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [GENERAL] Debugging deadlocks
Date
Msg-id 20050401013113.GA27341@dcc.uchile.cl
Whole thread Raw
List pgsql-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[@]dcc.uchile.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)

pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Hash vs. HashJoin nodes
Next
From: "Qingqing Zhou"
Date:
Subject: Re: [ADMIN] Excessive growth of pg_attribute and other system tables