Обсуждение: Selects query inside function must read commited data

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.

-- 
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.
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*

>
> 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

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 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  ,

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 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