RE: AW: AW: [HACKERS] TRANSACTIONS - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: AW: AW: [HACKERS] TRANSACTIONS
Date
Msg-id 000501bf7f2c$83c55720$2801007e@tpf.co.jp
Whole thread Raw
In response to AW: AW: AW: [HACKERS] TRANSACTIONS  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
List 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 by date:

Previous
From: Don Baccus
Date:
Subject: Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages
Next
From: Rolf Grossmann
Date:
Subject: Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0