On Tue, May 04, 2004 at 11:21:18PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > I've whacked the subtrans patch enough so that the simple tests (i.e.
> > non concurrent) for tuple visibility work. I can create a table and
> > populate it in subtransactions, rollback or commit them selectively and
> > get the desired effect at the end. Naturally, catalog entries also
> > behave [somewhat] sanely. Oh, I made pg_subtrans work too. (Though
> > whether it's relatively bug-free is yet to be proven.)
>
> I remember going through this. Other backends will use pg_subtrans to
> know what transactions are in progress. They have to do the standard
> lookups to find the status of the parent transaction. The backend-local
> list of xids is needed so the commit can clean up those subtransaction
> xids so that later transactions don't have to use pg_subtrans.
Ok, this can be done with what I have so far. I'm not sure how slow
will it be compared to checking the PGPROC struct, because it may
involve getting a pg_subtrans page from disk. Currently I have 8
pg_subtrans buffers on shared memory, the same as pg_clog; maybe we want
more to reduce that probability. 8 kB each, 2k xacts each, 16k xacts
total.
I'll test this and will probably be submitting a patch shortly.
> Sorry I haven't gotten your patches in yet. Tom is working on some
> other back patches.
I've been sloppy lately with #ifdef, because it takes some time to get
right and testing it takes even more time. I don't know if it's worth
it -- do you still have the idea of incremental, non disturbing patches?
> Also, do you have a plan to handle some of the more complex issues
> like locking in subtransactions?
Certainly. As soon as I have a concurrent scenario working, I'll pursue
the cleanup of all modules at subxact abort. (I have some working, some
which I know don't work, and some which I haven't tried yet.)
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Cada quien es cada cual y baja las escaleras como quiere" (JMSerrat)
