RE: AW: AW: [HACKERS] TRANSACTIONS

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: AW: AW: [HACKERS] TRANSACTIONS
Дата
Msg-id 000501bf7f2c$83c55720$2801007e@tpf.co.jp
обсуждение исходный текст
Ответ на AW: AW: AW: [HACKERS] TRANSACTIONS  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
Список pgsql-hackers
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Zeugswetter
> 
> > > They don't necessarily have nested tx, although some have.
> > > All they provide is atomicity of single statements.
> > 
> > If it looks like a duck, walks like a duck, and quacks like a duck,
> > it's a duck no matter what it's called.  How would you 
> > provide atomicity
> > of a single statement without a transaction-equivalent implementation?
> > That statement might be affecting many tuples in several different
> > tables.  It's not noticeably easier to roll back one statement than
> > a whole sequence of them.
> 
> Yes, the only difference seems to be, that the changes need not 
> be sync'd to disk, and you only need one level of nesting as long
> as the user is not presented the ability to use nested tx.
>

Hmm,what do you want now ?

Note that (f)sync is irrelevant at all.
Partial rollback is the problem of only the backend to be rollbacked
except locking.

Vadim has already planned savepoints functionality instead of nested
tx. I have never heard objections to the proposal.
I could see little difference between the implementation of rollback
to arbitrary savepoints and the implemention of rollback only to the
savepoint implicitly placed immediately before current statement. 

Do you want another hack ? 
Regards.

Hiroshi Inoue
Inoue@tpf.co.jp


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Don Baccus
Дата:
Сообщение: Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages
Следующее
От: Rolf Grossmann
Дата:
Сообщение: Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0