Re: Selects query inside function must read commited data

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: Andrew Biagioni <andrew(dot)biagioni(at)e-greek(dot)net>
Cc: aspire420(at)hotpop(dot)com, Oliver Elphick <olly(at)lfix(dot)co(dot)uk>, pgsql-admin(at)postgresql(dot)org
Subject: Re: Selects query inside function must read commited data
Date: 2004-01-26 14:30:35
Message-ID: 1075127435.22457.21032.camel@camel
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

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(at)jabber(dot)org <mailto:vishalkashyap(at)jabber(dot)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

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2004-01-26 14:39:58 Re: Problems with pg_dump
Previous Message Chris Travers 2004-01-26 13:17:57 Re: [SQL] Database diagram