Re: Clarification on a Time travel feature
От | Gokulakannan Somasundaram |
---|---|
Тема | Re: Clarification on a Time travel feature |
Дата | |
Msg-id | 9362e74e0711010305o7dc1f053v71596ee75da4913e@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Clarification on a Time travel feature ("Gokulakannan Somasundaram" <gokul007@gmail.com>) |
Список | pgsql-hackers |
There is one more condition under which this becomes useful. Suppose you have requirements for setting transaction isolation level as serializable only for select statements, you can avoid setting the transaction isolation level as serializable by making use of this feature. any expert comments?
--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Groups.
(www.alliedgroups.com)
On 10/31/07, Gokulakannan Somasundaram <gokul007@gmail.com> wrote:
There is only one condition under which this would be useful.
Current Scenario:
BEGIN
Select x into var from inventory where y=const;
update inventory..
some more DMLs.
some select into var2;
if (condition based on var2)
use the var;
END;
here i have to fire the first select query all the 100% of the time. Say if i have a feature to time travel within a transaction, i need to fire that select query on the probability of the condition based on var2 getting true.
After that implementation
BEGIN;
store command id and increment it into cid;
some DMLS
some select into var2
if(condition based on var2)
select into :var as of cid;
I know this is a small use-case. But if you think about it, the implementation is very easy. It wouldn't take much time to implement it.
Thanks,
Gokul.On 10/31/07, Heikki Linnakangas < heikki@enterprisedb.com > wrote:Gokulakannan Somasundaram wrote:
> a) Is there a proposal in place for going back in time within a transaction?
Within a transaction? No, can't remember one. Doesn't sound very useful.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Groups.
( www.alliedgroups.com)
--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Groups.
(www.alliedgroups.com)
В списке pgsql-hackers по дате отправления: