What are nested transactions then? was Nested transaction workaround?
От | Chris Travers |
---|---|
Тема | What are nested transactions then? was Nested transaction workaround? |
Дата | |
Msg-id | 022e01c3da8b$c2d58bb0$dd44053d@winxp обсуждение исходный текст |
Ответ на | Nested transaction workaround? ("John Sidney-Woollett" <johnsw@wardbrook.com>) |
Ответы |
Re: What are nested transactions then? was Nested transaction workaround?
Re: What are nested transactions then? was Nested transaction workaround? |
Список | pgsql-general |
From: "Martijn van Oosterhout" <kleptog@svana.org> > Well, actually, the problem appears to be that people want to be able to > roll back each individual statement without killing the parent transaction, > and they want to make this the default behaviour. This takes it out of the > "never used" category to "everybody does it" category. Ok. Now I am confused. I thought that a nested transaction would involve two features: 1: The ability to incrimentally commit/rollback changes, i.e. at certain points in the transaction have a sub-commit. 2: The ability to have a transaction within another transaction with transactional visibility rules applying within the transaction tree. What exactly do you mean by roll back individual statements? What exactly would be the default behavior? > There is > a bit of discussion on how to actually store that info in a way that can be > checked efficiently because remember, visibility needs to be checked for > every tuple on every sequential scan in every process that runs subsequently, > so it needs to be *fast*. Then you might have to have an array of "related transactions" which are also visible for each thransaction, sort of like a tree with bidirectional links. Unfortunately I can imagine this being a source of subtle, hard to troubleshoot bugs. Something like _x_id, _x_status, related_x_id[], child_x_id[], so that a rollback can rollback all child_x_id's without touching the other transactions which are parents, cousins, etc. but visible. Best Wishes, Chris Travers
В списке pgsql-general по дате отправления: