> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Zeugswetter
> Andreas IZ5
> Sent: Monday, December 28, 1998 6:30 PM
> To: hackers@postgreSQL.org
> Cc: 'vadim@krs.ru'
> Subject: Re: [HACKERS] MVCC works in serialized mode!
>
>
> >> Shouldn't we change default transaction mode now?
> >> And use option/SET TRANSACTION MODE to switch to
> >> un-chained mode if one like it?
> >
> >No comments on this?
> >I would like to make BEGIN implicit...
> >Objections?
>
> Yes, I object. I think the default behavior should be the one that
> is sufficient in most cases.
>
I have a question about new default(isolation level / transaction mode).
How do we upgrade existent programs,if default is different
from current ?
I think the isolation level of current PostgreSQL is SERIALIZABLE
and the transaction mode is un-chained..
As to the isolation level,even SERIALIZABLE isolaton level can't guarantee
the integrity of current level.
So we must change existent programs anyway ?
Thanks.
Hiroshi Inoue
Inoue@tpf.co.jp
> As to the isolation level:
> Informix and DB/2 default to read committed mode. In most cases this
> is
> sufficient.
> Therefore most clients don't need the extra set transaction
> isolation statement.
>
> As to transaction blocks:
> Actually most clients never use commit work, and remember
> that postgresql will never free it's memory before commit. This will
> hog up
> memory for otherwise lightweight clients.
>
> I also think that the begin work; commit work; statement block is
> somewhat part of the postgresql philosophy. We do not stand alone
> with this approach (Informix).
> Actually the other DB's start the transaction with the first
> modifying
> statement, in my opinion a rather weird approach.
> I have seen programs that do a dummy update, just to simulate a
> begin work, what a waste.
> But this alone will not work, because a select statement, that needs
>
> a sort would have started the transaction earlier (Since it created
> an implicit
> temp table).
> I could go on, but you see I don't really like this ......
>
> If you want to change the behavior, I think we will need a
> changeable default
> at database level.
>
> Andreas
>
>
>
>
>
