AW: AW: BLERe: AW: AW: relation ### modified while in u se
Are there many applications which have many SELECT statements(without
FOR UPDATE) in one tx ?Why not ?
It seems to me that multiple SELECT statements in a tx has little
meaning unless the tx is executed in SERIALIZABLE isolation level.E.g. a table is accessed multiple times to select different data
in an inner application loop. No need for serializable here.And seems no need to execute in one tx.
Yes there is, if you need to do dml based on the results of the inner loop
select statement.
Hmm,we seems to be able to call a cleanup procedure
internally which is equivalent to 'commit' after each
consecutive read-only statement. Is it a problem ?
Which would, in the locking sense be the same thing as
releasing the shared lock after each read only statement.
It would only be done if the current tx did not modify any
data yet. This is imho an awkward praxis that we should avoid at all
costs.
I have seen Oracle apps that start out with an update to a dummy
table, just to be sure the transaction started. This is nonsense,
that we imho don't want to copy.
Also the result would be, that the first readonly statements are allowed to
see schema changes, but selects after the first DML would not :-(
Andreas
Zeugswetter Andreas SB wrote:
[snip]
Also the result would be, that the first readonly statements are allowed to
see schema changes, but selects after the first DML would not :-(
Does it mean that even read-only statements aren't allowed
to release locks after other DMLs ?
Regards.
Hiroshi Inoue
I have not followed the entire thread, but if you are in a serializable OR
repeatable-read transaction,
Serializable and repeatable read are the same thing, different wording.
I would think that read-only statements will
need to keep some kind of lock on the rows they read (or the table).
Yes, we were talking about the other isolation levels. Most,
but not all of my mails in this thread state this difference.
Andreas
Import Notes
Resolved by subject fallback
At 09:36 25/10/00 +0200, Zeugswetter Andreas SB wrote:
I have not followed the entire thread, but if you are in a serializable OR
repeatable-read transaction,Serializable and repeatable read are the same thing, different wording.
Not last time I looked. RR ensures that rows you have seen will still
return the same data, but allows a reexecuted cursor to return more rows.
Serializable means cursors always return expected data the second time they
are executed.
I would think that read-only statements will
need to keep some kind of lock on the rows they read (or the table).Yes, we were talking about the other isolation levels. Most,
but not all of my mails in this thread state this difference.
The bit that worried me was that most emails only referred to serializable,
not RR (which they should have, I think).
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
Philip Warner wrote:
At 09:36 25/10/00 +0200, Zeugswetter Andreas SB wrote:
I have not followed the entire thread, but if you are in a serializable OR
repeatable-read transaction,Serializable and repeatable read are the same thing, different wording.
Not last time I looked. RR ensures that rows you have seen will still
return the same data, but allows a reexecuted cursor to return more rows.
Serializable means cursors always return expected data the second time they
are executed.
Currently PostgreSQL doesn't support REPEATABLE READ isolation level.
But we could use SERIALIZABLE isolation level instead of RR isolaiton level
because SERIALIZABLE isolation level satisfies the condition of RR isolation
level(as you mentioned above).
Show quoted text
I would think that read-only statements will
need to keep some kind of lock on the rows they read (or the table).Yes, we were talking about the other isolation levels. Most,
but not all of my mails in this thread state this difference.The bit that worried me was that most emails only referred to serializable,
not RR (which they should have, I think).----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/