Re: Nested Transaction TODO list

On Sat, Jul 03, 2004 at 11:03:33AM -0400, Tom Lane wrote:
> 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?

Hmm ... there are a lot of things in your list not in mine.  The things
that I have not in yours is pretty short:

- fix SPI to work on functions not-in-xact-block with TransactionStmt (this is related to the item on subxacts under
TBLOCK_STARTED)

- fix large objects longevity

Some comments:


> 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?

We should offer the savepoint syntax; seems easy to do.  I think a lot
of things are easier to do if we use a different syntax _and_ allow a
subxact to start from TBLOCK_STARTED.

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

It's a shame to have to lose backwards compatibility.  Why can't we use
ParameterStatus?  Perhaps having it as a GUC var was a bad idea, but we
can do otherwise.

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

Oversight.


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

We need to think about this and interaction with EOXact callbacks -- a
non-subxact-aware function could easily break if called inside a
subxact.


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

Can we use a cutoff like RecentGlobalXmin here?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"No reniegues de lo que alguna vez creíste"