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"