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.
Does anyone have a better idea? This is crucial.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Voy a acabar con todos los humanos / con los humanos yo acabaré
voy a acabar con todos / con todos los humanos acabaré (Bender)