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

Re: [HACKERS] Concurrency control questions 6.3.2 vs. 6.4

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: frampton(at)mail(dot)flarc(dot)edu(dot)on(dot)ca (Steve Frampton)
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Concurrency control questions 6.3.2 vs. 6.4
Date: 1998-12-13 02:30:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Hi everyone:
> Thanks for the helpful responses.  Are you folks getting sick of me yet?
> I'm hoping somebody could help me understand a bit better the way locking
> protocols are used in PostGreSQL 6.4, including how a query is parsed,
> executed, etc.
> I understand that there are two locks available: one for reads and one for
> writes.  They are called by RelationSetLockForRead() and 
> RelationSetLockForWrite(), respectively, which are both implemented in
> backend/storage/lmgr.c.
> These functions are called by the query parser, trigger handler, and
> indexing subsystem.  The query parser is responsible for parsing a given
> expression in backend/parser/parse_expr.c and actually grabbing tuples in
> backend/parser/parse_func.c which are passed as a heap array to the
> backend which in turn passes the information to the client. Am I still
> okay?
> I'm interested in the locking protocols as used for query processing
> so I guess I can ignore the trigger and indexing for now.
> Locking is not accomplished with calls to the operating system but instead
> is managed by the locking manager through a lock hash table which lives in
> shared memory. The table contains information on locks such as the type of
> lock (read/write), number of locks currently held, an array of bitmasks
> showing lock conflicts, and lock priority level (used to prevent
> starvation).  In addition, each relation has its own data structure which   
> includes some locking information.
> Here's where things get fuzzy -- there's a lot of code here so please be
> patient with me if I really screwed up in my interpretation.  :-)
> When the RelationSetLockFor...() function is called, it ensures that the
> relation and lock information for the relation are both valid.  It then
> calls MultiLockReln() with a pointer to the relation's lock information   
> and the appropriate lock type.  MultiLockReln() initializes a lock tag
> which is passed to MultiAcquire().
> I'm a little vague on MultiAcquire().  It seems to search through the
> lock hash table to see if a lock should be allowed?  And if so it calls
> LockAcquire().  But LockAcquire() itself checks for conflicts, sleeps if
> one exists, or sets the appropriate lock, adding it to the lock table.  So
> I'm a bit confused here...
> Unlocks are accomplished in much the same fashion.
> RelationUnsetLockFor...() is called which in turn calls MultiRelease()  
> which searches the lock table using the same algorithm as in
> MultiAcquire(). MultiRelease() calls LockRelease() which performs two
> functions.  First, it removes the lock information from the lock table.  
> Second, this function will awaken any transaction which had blocked
> waiting for the same lock. This is done here because if it was not, a new
> process could come along and request the lock causing a race condition.

Sounds pretty close.  I assume you have studied the backend flowcart on
the web support page and in src/tools/backend?

  Bruce Momjian                        |
  maillist(at)candle(dot)pha(dot)pa(dot)us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-12-13 03:37:41
Subject: Re: [HACKERS] 6.4.1 schedule SUNOS4.1.X build
Previous:From: Bruce MomjianDate: 1998-12-13 02:23:32
Subject: Re: Postgres for Sunos 4.1.4

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