Re: Nested Transaction TODO list - Mailing list pgsql-hackers
From | Alvaro Herrera |
---|---|
Subject | Re: Nested Transaction TODO list |
Date | |
Msg-id | 20040703161021.GB22242@dcc.uchile.cl Whole thread Raw |
In response to | Nested Transaction TODO list (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Nested Transaction TODO list
|
List | pgsql-hackers |
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"
pgsql-hackers by date: