AW: AW: BLERe: AW: AW: relation ### modified while in u se

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB
Тема AW: AW: BLERe: AW: AW: relation ### modified while in u se
Дата
Msg-id 11C1E6749A55D411A9670001FA6879633680C9@sdexcsrv1.f000.d0188.sd.spardat.at
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: Pete Forman
Дата:
Сообщение: Re: Re: Add support for
Следующее
От: Zeugswetter Andreas SB
Дата:
Сообщение: AW: AW: relation ### modified while in use