[subxacts] Open nested xact items

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: [subxacts] Open nested xact items
Date: 2004-07-12 18:32:49
Message-ID: 20040712183248.GB2925@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

List of open nested transactions items.

Implement named savepoint syntax, with SQL2003 semantics. Work in
progress, foundations done. Needs polishing and testing.

Fix issues with cursors. Need to mess with open portals at subxact abort.

Allow support for exceptions in functions. Allow registering at-subxact-abort
callback?

Report transaction nesting level to client. Use a non-GUC ParameterStatus
message when the nesting is changed?

Comments need work (xact.c and htup.h mainly)

Make TransactionIdIsInProgress more efficient. Make a subxid cache and a
negative xid cache. Short-circuit using RecentGlobalXmin. Bruce: use a
bit in tuple header to signal Xmin/Xmax was written on a subxact?

Marking children transactions as committed during transaction commit may
be wrong (or too costly to check). Prove/profile. Revert the change?

Make Catcache state saving more efficient. Maybe relcache too?

Correctly handle large objects. WIP.

Write documentation for the new syntax in SQL reference and in the tutorial.

Write regression tests.

Open questions from Tom:

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

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.

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)

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...)

*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.

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:
localbuf refcounts (decide if we are changing bufmgr behavior, first)
EOXact callbacks API needs extension
namespace (temp namespace cleanup)
files
password file
SetReindexProcessing

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
<Schwern> It does it in a really, really complicated way
<crab> why does it need to be complicated?
<Schwern> Because it's MakeMaker.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2004-07-12 19:41:16 Is "trust" really a good default?
Previous Message Ian Burrell 2004-07-12 18:03:02 Re: Memory management with C aggregate