Nested Transaction TODO list - Mailing list pgsql-hackers

Here's the promised list of things I think we still need to fix to
complete the nested-transactions project.  I assume you have a private
todo list as well --- can we compare notes?


Cursors have a whole range of issues, as is already under discussion.
Present design for bufmgr and indexscan cleanup may be all wrong.

Still need to agree about externally visible behavior (a different stmt
than begin/commit for subxacts?  What about savepoints?)  Also, what about
exposing this functionality in plpgsql?  Seems like we need some kind of
exception handling syntax to make this useful.  What does Oracle do?

What about reporting transaction state/nesting level to client?  I did not
like the GUC-variable approach in the original patch, partly on grounds of
efficiency and partly because I doubt it works under transaction-failure
conditions.  I'm inclined to think we need a small protocol change.
Perhaps it would work to add an additional field to Z messages that is
only sent when nest level > 1.

Need to think about pg_locks view now that single backend may have multiple
XIDs --- do we need more info in pg_locks??

Why does postgres.c discriminate against START TRANSACTION where it
now allows BEGIN?  Could simplify code by just allowing all
TransactionStmt types.

Does xact.c not allow a subtrans from TBLOCK_STARTED state?  Should fix.

I wonder whether we shouldn't rename TopTransactionContext.
Any existing references to TopTransactionContext are more than likely wrong
given the way its semantics have been subtly changed.  (I checked everything
in standard distro, but what about external PLs and user-written fns ...)

Check order of operations in subtransaction start/commit/abort.  Is there
a good reason not to be fully consistent with top-level cases?  Document
where there is.

trigger.c: not at all sure about the model for handling trigger firing
status.  It looks like a subtrans could fire triggers that were pending
from an outer xact, which is dubious at best.

Comments in htup.h now need work; seems a shame to just throw 'em away
but I guess that's what we use CVS for.

Couldn't we simplify IsSubTransaction into a check on nest depth?

plpgsql: is it okay for simple_eval_estate to live throughout
the toplevel xact?  subxact abort might release resources that
are still ref'd in estate, leading to trouble at top commit?
Maybe we need one simple_eval_estate per subxact ...

We should think about whether there's not a better way for
VACUUM FULL to work than session locks now.

xact_redo seems a bit optimistic about alignment?  Might be OK, not sure.
Need to test on alignment-picky box such as HP...

Not sure about logic for OnCommitActions, take another look.

DONE/CANCELED logic for triggers looks fishy too, particularly test at
line 1946ff (2003ff in my committed patch)

TransactionIdIsInProgress needs work/review; comments are off for one
thing, and it seems *way* too inefficient.  Note it should be possible to
skip subtrans search for sufficiently old xacts (hm ... couldn't we skip
sinval search too...)

catcache mechanism seems unacceptably inefficient as well.
Need to optimize on assumption that very few if any entries are pinned.

relcache same I think (although frequency with which entries will be
pinned is higher, and the total number of entries lower, so this is less
obviously sucky)

Most if not all of the uses of SubTransXidsHaveCommonAncestor should
probably go away, since it's rare to apply this test only once.  Better
to fold the probe XID to its toplevel parent once instead of N times.

More generally, we have replaced cheap tests with expensive ones in
many places in tqual.c; this needs more thought.

Note TransactionIdIsCurrentTransactionId has become much looser.
Need to look at its uses ... (seems okay in a quick look but I'm not
totally convinced...)

XactLockTableWait --- annoying that it waits for top xact even when subtrans
has already aborted; possibly even a recipe for deadlock.  Probably better
if we make subtransactions take out locks on their own XIDs, same as top
level.  If these are held till commit/abort same as other locks, I think
we can simply revert XactLockTableWait to its prior state and it will do
just the right thing.

*why* can't you make a subtrans read only?  (Probably just temporary
until GUC rollback is worked on?)  See assign_transaction_read_only.
Need to make sure you can't loosen the constraint, though (no r/w
subxact of r/o parent), so we do need an assign hook to check that.

Seems like subtrans could/should be truncated much sooner than clog.
What we need here is a short-circuit test to avoid pursuing parent of
a subtrans older than, say, RecentGlobalXmin.  If it isn't yet marked
committed then it must be aborted, no need to look at parent.
But think about race conditions and order of marking subxacts during
commit/abort.

[older version of same thought] Truncating subtrans log needs more thought
--- race conditions about when/whether a subxact is properly marked in
main clog as committed or aborted?  I think we need to be able to assume
that subxact-commit state in clog actually means aborted, *without*
visiting subtrans, before some cutoff point.  This is okay as long as the
cutoff point cannot advance past a main xact that is busy marking its
subtranses as committed.  Check order of operations during commit.
Probably need to stay "in progress" in sinval until after all subtrans
marked.

Don't much like using lfirst_int etc for XIDs ... probably should
at least invent some macros lfirst_xid and so on.

Stuff that still needs examination:
lo_commit
localbuf refcounts (decide if we are changing bufmgr behavior, first)
EOXact callbacks API needs extension
namespace (temp namespace cleanup)
files
password file
SetReindexProcessing

        regards, tom lane