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

Re: Shared row locking

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>,Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Shared row locking
Date: 2004-12-19 04:04:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
BTom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > You mean all empty/zero rows can be removed?  Can we guarantee that on
> > commit we can clean up the bitmap?  If not the idea doesn't work.
> For whatever data structure we use, we may reset the structure to empty
> during backend-crash recovery.  So your objection boils down to "what if
> a backend exits normally but forgets to clean up its locks?"  Assuming
> that doesn't happen isn't any worse than assuming a backend will clean
> up its shared memory state on non-crash exit, so I don't think it's a
> serious concern.
> That brings another thought: really what this is all about is working
> around the fact that the standard lock manager can only cope with a
> finite number of coexisting locks, because it's working in a fixed-size
> shared memory arena.  Maybe we should instead think about ways to allow
> the existing lock table to spill to disk when it gets too big.  That
> would eliminate max_locks_per_transaction as a source of hard failures,
> which would be a nice benefit.

Agreed. Once concern I have about allowing the lock table to spill to
disk is that a large number of FOR UPDATE locks could push out lock
entries used by other backends, causing very poor performance.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2004-12-19 04:27:06
Subject: Re: Identifying time of last stat reset via sql
Previous:From: Joe ConwayDate: 2004-12-19 03:34:02
Subject: Re: production server down

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