Alvaro Herrera wrote:
> Hackers,
>
> 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'm now looking at changing the concurrent visibility rules, i.e.
> utils/time/tqual.c. It seems to me one of the most important parts is
> making TransactionIdIsInProgress() behave, that is, yield true for every
> committed and in-progress subtransaction of a current transaction tree.
> (Not only the topmost Xid, which is what it currently does.)
>
> So, the big question is, how do we do this? The most obvious way (to
> me) is to keep the whole array inside the PGPROC struct. This would be
> nice because it would only need little modification to
> access/transam/varsup.c. The main downside is that it potentially
> requires a lot of shared memory. Can we afford that?
>
> I am already keeping the list of committed Xids in a backend-local list,
> but of course this is not visible to other backends.
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.
Does this help?
Sorry I haven't gotten your patches in yet. Tom is working on some
other back patches. Also, do you have a plan to handle some of the more
complex issues like locking in subtransactions?
-- 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
