Re: foreign key locks, 2nd attempt - Mailing list pgsql-hackers

From Gokulakannan Somasundaram
Subject Re: foreign key locks, 2nd attempt
Date
Msg-id CAHMh4-YY3AGrPRQ4jqzjB97KtWj7SFg_tztMh7k4yPJtWyDWKw@mail.gmail.com
Whole thread Raw
In response to Re: foreign key locks, 2nd attempt  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: foreign key locks, 2nd attempt  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
I feel sad, that i followed this topic very late. But i still want to put forward my views. 
Have we thought on the lines of how Robert has implemented relation level locks. In short it should go like this

a) The locks for enforcing Referential integrity should be taken only when the rarest of the events( that would cause the integrity failure) occur. That would be the update of the referenced column. Other cases of update, delete and insert should not be required to take locks. In this way, we can reduce a lot of lock traffic.

So if we have a table like employee( empid, empname, ... depid references dept(deptid)) and table dept(depid depname).

Currently we are taking shared locks on referenced rows in dept table, whenever we are updating something in the employee table. This should not happen. Instead any insert / update of referenced column / delete should check for some lock in its PGPROC structure, which will only get created when the depid gets updated / deleted( rare event )

b) But the operation of update of the referenced column will be made more costly. May be it can create something like a predicate lock(used for enforcing serializable) and keep it in all the PG_PROC structures. 

I know this is a abstract idea, but just wanted to know, whether we have thought on those lines.

Thanks,
Gokul.


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
Next
From: Marko Kreen
Date:
Subject: Re: [9.2] Confusion over CacheRegisterSyscacheCallback