Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling

Christopher Kings-Lynne wrote:
> > I think the speed complaint I was just raising could possibly be
> > answered by setting an infomask bit indicating that the row might
> > be present in a separate table of active row locks.  (I'm not sure
> > how the bit would get cleared without race conditions, but let's
> > suppose that can be done.)  A little hashing, a little spill-to-disk
> > logic, and it might be done.  But that's just handwaving... anyone
> > want to try to fill in the details?
> 
> I vote Alvaro :)  This stuff is way out of my league - I'm just the 
> ideas man :D
> 
> Either way - Bruce, did you want to add a summary of these ideas to the 
> TODO?

OK, TODO updated:

* Implement dirty reads or shared row locks and use them in RI triggers
 Adding shared locks requires recording the table/rows numbers in a shared area, and this could potentially be a large
amountof data. One idea is to store the table/row numbers in a separate table and set a bit on the row indicating
lookingin this new table is required to find any shared row locks.
 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073