From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | AW: AW: BLERe: AW: AW: relation ### modified while in u se |
Date: | 2000-10-24 09:41:48 |
Message-ID: | 11C1E6749A55D411A9670001FA6879633680C9@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB | 2000-10-24 09:51:48 | AW: AW: relation ### modified while in use |
Previous Message | Pete Forman | 2000-10-24 09:40:34 | Re: Re: Add support for <xti.h> |