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 amount of data.
One idea is to store the table/row numbers in a separate table and set
a bit on the row indicating looking in this new table is required to
find any shared row locks.

--
Bruce Momjian | http://candle.pha.pa.us
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