Re: AW: BLERe: AW: AW: relation ### modified whilein use

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: BLERe: AW: AW: relation ### modified whilein use
Date: 2000-10-25 06:40:49
Message-ID: 39F68071.39D665BD@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Philip Warner wrote:

> At 18:31 24/10/00 +0900, Hiroshi Inoue wrote:
> >
> >
> >Zeugswetter Andreas SB wrote:
> >
> >> > > > 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.
> >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 ?
>
> I have not followed the entire thread, but if you are in a serializable OR
> repeatable-read transaction, I would think that read-only statements will
> need to keep some kind of lock on the rows they read (or the table).
>

Currently read-only statements keep AccessShareLock on the table
(not on the rows) until the end of the statement and none objects
to it. What we've discussed is whether we should keep the lock
until the end of tx or not in read committed mode.

Regards.
Hiroshi Inoue

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2000-10-25 06:47:40 Re: AW: BLERe: AW: AW: relation ### modified while in use
Previous Message Thomas Lockhart 2000-10-25 03:22:06 Re: Fallback behavior for "UNKNOWN" types -- proposed change