From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Debugging deadlocks |
Date: | 2005-03-30 23:17:37 |
Message-ID: | 20050330231737.GA24418@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Mar 30, 2005 at 05:41:04PM -0500, Greg Stark wrote:
>
> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
>
> > 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 ...
>
> Is that true even if I'm updating/deleting 1,000 tuples that all reference the
> same foreign key? It seems like that should only need a single lock per
> (sub)transaction_id per referenced foreign key.
Well, in that case you need 1000 PROCLOCK objects, all pointing to the
same LOCK object. But it still uses shared memory.
> How is this handled currently? Is your patch any worse than the current
> behaviour?
With my patch it's useless without a provision to spill the lock table.
The current situation is that we don't use the lock table to lock
tuples; instead we mark them on disk, in the tuple itself. So we can't
really mark a tuple more than once (because we have only one bit to
mark); that's why we limit tuple locking to exclusive locking (there's
no way to mark a tuple with more than one shared lock).
With my patch we need a lot of memory for each tuple locked. This needs
to be shared memory. Since shared memory is limited, we can't grab an
arbitrary number of locks simultaneously. Thus, deleting a whole table
can fail. You haven't ever seen Postgres failing in a DELETE FROM
table, have you?
--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"Java is clearly an example of a money oriented programming" (A. Stepanov)
From | Date | Subject | |
---|---|---|---|
Next Message | Edson Vilhena de Carvalho | 2005-03-30 23:32:56 | Database monitoring |
Previous Message | Dann Corbit | 2005-03-30 23:16:19 | Re: Days in month query |