> > The problem at hand is that
> > a plan may be invalidated before it is even finished building. Do you
> > expect the parse-rewrite-plan-execute pipeline to be prepared to back up
> > and restart if we notice a relation schema change report halfway down the
> > process?
Yes, during the proce
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 s
> 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 tabl
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
>
> > > > > 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.
> >
>
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.
Hi
> More of that - while one xaction will wait to alter a table no new xaction
> will be allowed to access this table too.
Yes, I forgot, that placing an exclusive lock will make later shared lock
requests wait.
Andreas
> > 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 ?
That is, what Tom is suggesting, but not afte
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 isol
> > > 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 multipl
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > Yes, and holding a row exclusive lock must imho at least
> grab a shared
> > table lock
>
> As indeed it does. Our disagreement seems to be just on the point of
> whether it's safe to allow a read-only transaction to release its
> Acces
Zeugswetter Andreas SB wrote:
> > > > What I'm proposing is that once an xact has touched a
> > > > table, other xacts should not be able to apply schema updates to that
> > > > table until the first xact commits.
> > >
> > > No, this would mean too many locks, and would leave the dba with hardl
At 10:10 23/10/00 -0400, Tom Lane wrote:
>
>I consider that behavior *far* safer than allowing schema changes to
>be seen mid-transaction. Consider the following example:
>
> Session 1 Session 2
>
> begin;
>
> INSERT INTO foo ...;
>
>
> > As for locks,weak locks doesn't pass intensive locks. Dba
> > seems to be able to alter a table at any time.
>
> Sorry, I don't understand this sentence. Tom suggested placing a shared
lock on
> any table that is accessed until end of tx. Noone can alter table until
all users have
> closed the
Philip Warner <[EMAIL PROTECTED]> writes:
> In this case, wouldn't the answer depend on the isolation level of session
> 1? For serializable TX, then constraint would not apply; 'read committed'
> would mean the constraint was visible on the second insert and at the commit.
The important issue he
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Yes, and holding a row exclusive lock must imho at least grab a shared
> table lock
As indeed it does. Our disagreement seems to be just on the point of
whether it's safe to allow a read-only transaction to release its
AccessShareLock locks p
> > You were talking about the "select only" case (and no for update eighter).
> > I think that select statements need a shared lock for the duration of their
> > execution only.
>
> You seem to think that locks on individual tuples conflict with
> table-wide locks.
Yes, very much so. Any oth
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> No, the above is not a valid example, because Session 2 won't
> get the exclusive lock until Session 1 commits, since Session 1 already
> holds a lock on foo (for the inserted row).
> You were talking about the "select only" case (and no for
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> As for locks,weak locks doesn't pass intensive locks. Dba
>> seems to be able to alter a table at any time.
> Sorry, I don't understand this sentence. Tom suggested placing a
> shared lock on any table that is accessed until end of tx. Noone
> Until existing xacts using that table have closed, yes. But I believe
> the lock manager has some precedence rules that will allow the pending
> request for AccessExclusiveLock to take precedence over new requests
> for lesser locks. So you're only held off for a long time if you have
> long-
Zeugswetter Andreas SB wrote:
> > What I'm proposing is that once an xact has touched a
> > table, other xacts should not be able to apply schema updates to that
> > table until the first xact commits.
>
> No, this would mean too many locks, and would leave the dba with hardly a
> chance to alte
> > > What I'm proposing is that once an xact has touched a
> > > table, other xacts should not be able to apply schema updates to that
> > > table until the first xact commits.
> >
> > No, this would mean too many locks, and would leave the dba with hardly a
> > chance to alter a table.
> >
>
>
> What I'm proposing is that once an xact has touched a
> table, other xacts should not be able to apply schema updates to that
> table until the first xact commits.
No, this would mean too many locks, and would leave the dba with hardly a
chance to alter a table.
If I recall correctly the ANS
23 matches
Mail list logo
