From: Erik Wasser <erik.wasser@iquer.net>
To: pgsql-sql@postgresql.org
Subject: Re: Are long term never commited SELECT statements are a problem?
Date: Thu, 21 Jul 2005 17:40:57 +0200
User-Agent: KMail/1.8.1
References: <200507211557.58822.erik.wasser@iquer.net>
	<20050721151811.GA513@winnie.fuhr.org>
In-Reply-To: <20050721151811.GA513@winnie.fuhr.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200507211740.57999.erik.wasser@iquer.net>

On Thursday 21 July 2005 17:18, Michael Fuhr wrote:

> If you set AutoCommit to 0 then all statements are inside a
> transaction.  As you've discovered, SELECT acquires certain locks
> that persist for the duration of the transaction, so you must commit
> or roll back the transaction to release those locks (read up on
> transaction theory to learn more about the rationale for this).

What URL should I read at first? I began with 
'http://www.postgresql.org/docs/8.0/interactive/transaction-iso.html'. 
Is this the right page for starters?

BTW: I quote from the page:

> When a transaction is on the serializable level, a SELECT query sees
> only data committed before the transaction began; it never sees either
> uncommitted data or changes committed during transaction 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.)     

So I opened up two shells and started 'psql' on both shells (marked the 
command with 1 and 2):

1:begin

2:begin;

1:SELECT * FROM test;
 id | name
----+------
(0 rows)

2: INSERT INTO test (name) VALUES ('foo');

1: SELECT * FROM test;
 id | name
----+------
(0 rows)

2: commit;

1: SELECT * FROM test;
 id | name
----+------
  1 | foo
(1 row)

Why do I see in the first transaction data from the commited second 
transaction? Doesn't prove that the documentation on the above URL 
wrong?

-- 
So long... Fuzz