Re: Shared row locking - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Shared row locking
Date
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3412A757A@Herge.rcsinc.local
Whole thread Raw
In response to Shared row locking  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Re: Shared row locking
List pgsql-hackers
Tom lane wrote:
> Gavin Sherry <swm@linuxworld.com.au> writes:
> > I think if we allow the lock manager to spill to disk (and I think
we do
> > need to allow it) then we should also be able to control the amount
of
> > shared memory allocated.
>
> You mean like max_locks_per_transaction?

IMO, max_locks_per_transaction could use a better name a little more
documentation.  I've mentioned this a couple of times before, but there
is at least one type of lock that does not expire when the transaction
ends (user locks).

I may be over my head here, but I think lock spillover is dangerous.  In
the extreme situations where this would happen, it would be a real
performance buster.  Personally, I would rather see locks escalate when
the table gets full, or at least allow this as a configuration
parameter.

Merlin






pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Help extending pg_class
Next
From: Tom Lane
Date:
Subject: Re: Shared row locking