AW: AW: BLERe: AW: AW: relation ### modified while in u se - Mailing list pgsql-hackers

From Zeugswetter Andreas SB
Subject AW: AW: BLERe: AW: AW: relation ### modified while in u se
Date
Msg-id 11C1E6749A55D411A9670001FA6879633680C9@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
List pgsql-hackers
> > > > > 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


pgsql-hackers by date:

Previous
From: Pete Forman
Date:
Subject: Re: Re: Add support for
Next
From: Zeugswetter Andreas SB
Date:
Subject: AW: AW: relation ### modified while in use