Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] MVCC works in serialized mode!

From: Zeugswetter Andreas IZ5 <Andreas(dot)Zeugswetter(at)telecom(dot)at>
To: hackers(at)postgreSQL(dot)org
Cc: "'vadim(at)krs(dot)ru'" <vadim(at)krs(dot)ru>
Subject: Re: [HACKERS] MVCC works in serialized mode!
Date: 1998-12-28 09:30:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
	>>    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...

	Yes, I object. I think the default behavior should be the one that 
	is sufficient in most cases. 

	As to the isolation level: 
	Informix and DB/2 default to read committed mode. In most cases this
	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
	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.



pgsql-hackers by date

Next:From: Theo KramerDate: 1998-12-28 14:04:56
Subject: Re: [HACKERS] MVCC works in serialized mode!
Previous:From: Angelos KarageorgiouDate: 1998-12-28 08:27:55
Subject: Re: [HACKERS] psql \d does not work

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group