Thread: Selects query inside function must read commited data
Selects query inside function must read commited data
From
"V i s h a l Kashyap @ [Sai Hertz And Control Systems]"
Date:
Dear all ,
Would like to receive your kind attention and enormous knowledge on the following
I have a function
sai_func_a()
Which does as follows and in the same order:
1. Retrieves the latest record from the table test_sai
(By latest I mean the record corresponding to max primary key of the table)
2. Increments date as received from test_sai.current_date
as my_new_date := test_sai.current_date + 1 ;
3. Inserts the new date into the same table test_sai
4. Calls another function sai_func_b()
Now inside sai_func_b()
1. Does as #1 of above
2. Works on the date in the last record.
3. Returns success code to sai_func_a()
5. The sai_func_a() finishes the work
Now My question :
Since sai_func_a() which encapsulates the function sai_func_b has not completed yet till #4 or #5
then how does the function sai_func_b reads the new data since it is not committed yet.
If I am not wrong PostgreSQL select statements works on committed data thus the new
inserted data at #3 must not be available to sai_func_b() till #5
Server Specs:
1. version
---------------------------------------------------------------------------------------------------------
PostgreSQL 7.3.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
2.Both functions are plpgsql and are not triggers
If you need more information kindly ask for the same.
Would like to receive your kind attention and enormous knowledge on the following
I have a function
sai_func_a()
Which does as follows and in the same order:
1. Retrieves the latest record from the table test_sai
(By latest I mean the record corresponding to max primary key of the table)
2. Increments date as received from test_sai.current_date
as my_new_date := test_sai.current_date + 1 ;
3. Inserts the new date into the same table test_sai
4. Calls another function sai_func_b()
Now inside sai_func_b()
1. Does as #1 of above
2. Works on the date in the last record.
3. Returns success code to sai_func_a()
5. The sai_func_a() finishes the work
Now My question :
Since sai_func_a() which encapsulates the function sai_func_b has not completed yet till #4 or #5
then how does the function sai_func_b reads the new data since it is not committed yet.
If I am not wrong PostgreSQL select statements works on committed data thus the new
inserted data at #3 must not be available to sai_func_b() till #5
Server Specs:
1. version
---------------------------------------------------------------------------------------------------------
PostgreSQL 7.3.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
2.Both functions are plpgsql and are not triggers
If you need more information kindly ask for the same.
-- Regards, Vishal Kashyap ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* I Know you believe my words so logon to Jabber.org and add vishalkashyap@jabber.org to your roster. ~*~*~*~*~*~*~*~* I am usually called as Vishal Kashyap but my Girl friend calls me as Vishal CASH UP. This is because others know me because of my generosity and my Girlfriend knows me because of my CASH. ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Re: Selects query inside function must read commited data
From
"V i s h a l Kashyap @ [Sai Hertz And Control Systems]"
Date:
> > Would like to receive your kind attention and enormous knowledge on > the following This tickles me > > I have a function So what ? > sai_func_a() > Which does as follows and in the same order: > 1. Retrieves the latest record from the table test_sai > (By latest I mean the record corresponding to max primary key of > the table) > 2. Increments date as received from test_sai.current_date > as my_new_date := test_sai.current_date + 1 ; > 3. Inserts the new date into the same table test_sai > 4. Calls another function sai_func_b() > Now inside sai_func_b() > 1. Does as #1 of above > 2. Works on the date in the last record. > 3. Returns success code to sai_func_a() > 5. The sai_func_a() finishes the work > > Now My question : No one is intrested in your question and thus no answers > Since sai_func_a() which encapsulates the function sai_func_b has not > completed yet till #4 or #5 > then how does the function sai_func_b reads the new data since it is > not committed yet. > > If I am not wrong PostgreSQL select statements works on committed data > thus the new > inserted data at #3 must not be available to sai_func_b() till #5 > > Server Specs: > 1. version > --------------------------------------------------------------------------------------------------------- > PostgreSQL 7.3.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2 > 20030222 (Red Hat Linux 3.2.2-5) > 2.Both functions are plpgsql and are not triggers > > > > If you need more information kindly ask for the same. Yes, I need one Why did you ask this question ? -- Regards, Vishal Kashyap ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* I Know you believe my words so logon to Jabber.org and add vishalkashyap@jabber.org to your roster. ~*~*~*~*~*~*~*~* I am usually called as Vishal Kashyap but my Girlfriend calls me as Vishal CASH UP. This is because others identify me because of my generosity but my Girlfriend identify me because of my CASH. ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
On Sun, 2004-01-25 at 08:51, V i s h a l Kashyap @ [Sai Hertz And Control Systems] wrote: > Since sai_func_a() which encapsulates the function sai_func_b has not > completed yet till #4 or #5 > then how does the function sai_func_b reads the new data since it is > not committed yet. > > If I am not wrong PostgreSQL select statements works on committed data > thus the new > inserted data at #3 must not be available to sai_func_b() till #5 No. All operations by a single transaction are visible inside the transaction. Therefore an encapsulated function can see anything already done in the whole transaction. A function must be entirely inside a transaction and cannot start a transaction, so there can never be any problem about this. Within a transaction, you cannot see data committed by any _other_ transaction that had not already committed when your transaction started. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "My little children, let us not love in word, neither in tongue; but in deed and in truth." I John 3:18
Re: Selects query inside function must read commited data
From
"V i s h a l Kashyap @ [Sai Hertz And Control Systems]"
Date:
Dear Oliver Elphick ,
Would be greatefull if you kindly post some links/refrences to support your answer for the said.
Thanks one again .
Loads of thanks for the kind reply .If I am not wrong PostgreSQL select statements works on committed data thus the new inserted data at #3 must not be available to sai_func_b() till #5No. All operations by a single transaction are visible inside the transaction. Therefore an encapsulated function can see anything already done in the whole transaction. A function must be entirely inside a transaction and cannot start a transaction, so there can never be any problem about this.
Would be greatefull if you kindly post some links/refrences to support your answer for the said.
Thanks one again .
-- Regards, Vishal Kashyap ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* I Know you believe my words so logon to Jabber.org and add vishalkashyap@jabber.org to your roster. OR Seek Me at 264360076 ~*~*~*~*~*~*~*~* I am usually called as Vishal Kashyap but my Girlfriend calls me as Vishal CASH UP. This is because others identify me because of my generosity but my Girlfriend identify me because of my CASH. ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
On Sun, 2004-01-25 at 16:31, V i s h a l Kashyap @ [Sai Hertz And Control Systems] wrote: > Dear Oliver Elphick , > > > If I am not wrong PostgreSQL select statements works on committed data > > > thus the new > > > inserted data at #3 must not be available to sai_func_b() till #5 > > > > > No. All operations by a single transaction are visible inside the > > transaction. Therefore an encapsulated function can see anything already > > done in the whole transaction. A function must be entirely inside a > > transaction and cannot start a transaction, so there can never be any > > problem about this. > > > Loads of thanks for the kind reply . > Would be greatefull if you kindly post some links/refrences to support > your answer for the said. It's in the manual, somewhere; or try it and verify that what I say is correct. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "My little children, let us not love in word, neither in tongue; but in deed and in truth." I John 3:18
In the v7.3 docs:
http://www.postgresql.org/docs/7.3/interactive/transaction-iso.html#XACT-READ-COMMITTED
Read Committed is the default isolation level in PostgreSQL. When a transaction runs on this isolation level, a SELECT query sees only data committed before the query began; it never sees either uncommitted data or changes committed during query execution by concurrent transactions. (However, the SELECT does see the effects of previous updates executed within its own transaction, even though they are not yet committed.) In effect, a SELECT query sees a snapshot of the database as of the instant that that query begins to run. Notice that two successive SELECTs can see different data, even though they are within a single transaction, if other transactions commit changes during execution of the first SELECT.
Andrew
V i s h a l Kashyap @ [Sai Hertz And Control Systems] wrote:
Dear Oliver Elphick ,
Would be greatefull if you kindly post some links/refrences to support your answer for the said.
Thanks one again .
http://www.postgresql.org/docs/7.3/interactive/transaction-iso.html#XACT-READ-COMMITTED
Read Committed is the default isolation level in PostgreSQL. When a transaction runs on this isolation level, a SELECT query sees only data committed before the query began; it never sees either uncommitted data or changes committed during query execution by concurrent transactions. (However, the SELECT does see the effects of previous updates executed within its own transaction, even though they are not yet committed.) In effect, a SELECT query sees a snapshot of the database as of the instant that that query begins to run. Notice that two successive SELECTs can see different data, even though they are within a single transaction, if other transactions commit changes during execution of the first SELECT.
Andrew
V i s h a l Kashyap @ [Sai Hertz And Control Systems] wrote:
Dear Oliver Elphick ,
Loads of thanks for the kind reply .If I am not wrong PostgreSQL select statements works on committed data thus the new inserted data at #3 must not be available to sai_func_b() till #5No. All operations by a single transaction are visible inside the transaction. Therefore an encapsulated function can see anything already done in the whole transaction. A function must be entirely inside a transaction and cannot start a transaction, so there can never be any problem about this.
Would be greatefull if you kindly post some links/refrences to support your answer for the said.
Thanks one again .
-- Regards, Vishal Kashyap ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* I Know you believe my words so logon to Jabber.org and add vishalkashyap@jabber.org to your roster. OR Seek Me at 264360076 ~*~*~*~*~*~*~*~* I am usually called as Vishal Kashyap but my Girlfriend calls me as Vishal CASH UP. This is because others identify me because of my generosity but my Girlfriend identify me because of my CASH. ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
All this is well and good, but inside a function you might not see data that is committed since the query snapshot is not updated within a function. Search on setQuerySnapshot in the pgsql-bugs list and I think you'll find more info. So far no one has come up with the evidence needed to convince the core developers to change this behavior. Robert Treat On Sun, 2004-01-25 at 13:09, Andrew Biagioni wrote: > In the v7.3 docs: > > http://www.postgresql.org/docs/7.3/interactive/transaction-iso.html#XACT > -READ-COMMITTED > <http://www.postgresql.org/docs/7.3/interactive/transaction-iso.html#XAC > T-READ-COMMITTED> > > Read Committed is the default isolation level in PostgreSQL. When a > transaction runs on this isolation level, a SELECT query sees only data > committed before the query began; it never sees either uncommitted data > or changes committed during query execution by concurrent transactions. > (However, the SELECT does see the effects of previous updates executed > within its own transaction, even though they are not yet committed.) In > effect, a SELECT query sees a snapshot of the database as of the instant > that that query begins to run. Notice that two successive SELECTs can > see different data, even though they are within a single transaction, if > other transactions commit changes during execution of the first SELECT. > > Andrew > > V i s h a l Kashyap @ [Sai Hertz And Control Systems] wrote: > > > Dear Oliver Elphick , > > > If I am not wrong PostgreSQL select statements works on committed data > > thus the new > > inserted data at #3 must not be available to sai_func_b() till #5 > > > > > > No. All operations by a single transaction are visible inside the > > transaction. Therefore an encapsulated function can see anything already > > done in the whole transaction. A function must be entirely inside a > > transaction and cannot start a transaction, so there can never be any > > problem about this. > > > > Loads of thanks for the kind reply . > Would be greatefull if you kindly post some links/refrences to support > your answer for the said. > Thanks one again . > > > > -- > > Regards, > > Vishal Kashyap > > > > ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* > > I Know you believe my words so logon to Jabber.org > > and add vishalkashyap@jabber.org <mailto:vishalkashyap@jabber.org> to > your roster. > > OR > > Seek Me at 264360076 > > ~*~*~*~*~*~*~*~* > > I am usually called as Vishal Kashyap > > but my Girlfriend calls me as Vishal CASH UP. > > This is because others identify me because of my generosity > > but my Girlfriend identify me because of my CASH. > > ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* > > > -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL