Re: Are long term never commited SELECT statements are a problem?

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