Обсуждение: Re: [HACKERS] tablelevel and rowlevel locks

Поиск
Список
Период
Сортировка

Re: [HACKERS] tablelevel and rowlevel locks

От
"Jenny -"
Дата:
>On Thu, Sep 04, 2003 at 08:56:31AM -0700, Jenny - wrote:
> > I am working on a project that involves displaying locking information
> > about each lock taken, whether it be a row level or  table leve llock.
> > When dealing with struct LOCK (src/include/storage) i have noticed that
> > postgreSQL creates a single LOCK  struct for each table in the  db. Like
>if
> > i acquire 2 seperate row level locks on 2 seperate rows, both these
>locks
> > are represented in the same struct LOCK datastructure.
>
>I think the locks would actually by represented by PROCLOCK structures.
>The LOCK structures are for lockable objects, not for actual locks.
>

Well,from what i understand, PROCLOCK stores the TransactionID and the LOCK
its holding lock on ,so
how would PROCLOCK be holding the 'actual' lock as apposed to the lockable
objects?
thanks!

_________________________________________________________________
Use custom emotions -- try MSN Messenger 6.0!
http://www.msnmessenger-download.com/tracking/reach_emoticon


Re: [HACKERS] tablelevel and rowlevel locks

От
Alvaro Herrera Munoz
Дата:
On Thu, Sep 04, 2003 at 11:21:05AM -0700, Jenny - wrote:

> >I think the locks would actually by represented by PROCLOCK structures.
> >The LOCK structures are for lockable objects, not for actual locks.
>
> Well,from what i understand, PROCLOCK stores the TransactionID and the LOCK
> its holding lock on ,so how would PROCLOCK be holding the 'actual' lock as
> apposed to the lockable objects?

Huh... look at http://developer.postgresql.org/pdf/internalpics.pdf pages 61 and 63.
Maybe it's clearer than whatever I can say.  Note that "HOLDER" has been renamed
to "PROCLOCK".

Anyway, I think the LOCK structure represents something that can be locked.
The PROCLOCK struct represents that some process is holding a lock on said
object.  That may be the reason why you are seeing that a lock is held by more
than one process at the same time (while in fact some of them are probably
_waiting_ for the lock).

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"I dream about dreams about dreams", sang the nightingale
under the pale moon (Sandman)

Re: [HACKERS] tablelevel and rowlevel locks

От
Tom Lane
Дата:
Alvaro Herrera Munoz <alvherre@dcc.uchile.cl> writes:
> Anyway, I think the LOCK structure represents something that can be locked.

Right.

> The PROCLOCK struct represents that some process is holding a lock on said
> object.

IIRC, a PROCLOCK is created as soon as some backend tries to lock some
lockable object.  So the PROCLOCK may only indicate that that backend is
waiting for a lock on that object, not that it already has one.

> That may be the reason why you are seeing that a lock is held by more
> than one process at the same time (while in fact some of them are probably
> _waiting_ for the lock).

Also keep in mind that we use a lot of sharable lock modes --- so it's
entirely likely that multiple processes actually do have locks on the
same object.  That's not wrong if their lock modes don't conflict.

            regards, tom lane