Vadim Mikheev wrote:
> > > in general. 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.
> > >
> >
> > I agree with you.
>
> I don't know. We discussed this issue just after 6.5 and decided to
> allow concurrent schema modifications.
> Oracle has disctionary locks but run each DDL statement in separate
> xaction, so - no deadlock condition here. OTOH, I wouldn't worry
> about deadlock - one just had to follow common anti-deadlock rules.
>
> > I've wondered why AccessShareLock is a short term lock.
>
> MUST BE. AccessShare-/Exclusive-Locks are *data* locks.
> If one want to protect schema then new schema share/excl locks
> must be inroduced. There is no conflict between data and
> schema locks - they are orthogonal.
>
Oracle doesn't have Access...Lock locks.
In my understanding,locking levels you provided contains
an implicit share/exclusive lock on the corrsponding
pg_class tuple i.e. AccessExclusive Lock acquires an
exclusive lock on the corresping pg_class tuple and
other locks acquire a share lock, Is it right ?
>
> We use AccessShare-/Exclusive-Locks for schema because of...
> we allow concurrent schema modifications and no true schema
> locks were required.
>
> > If we have a mechanism to acquire a share lock on a tuple,we
> > could use it for managing system info generally. However the
> > only allowed lock on a tuple is exclusive. Access(Share/Exclusive)
>
> Actually, just look at lock.h:LTAG structure - lock manager supports
> locking of "some objects" inside tables:
>
> typedef struct LTAG
> {
> Oid relId;
> Oid dbId;
> union
> {
> BlockNumber blkno;
> Transaction xid;
> } objId;
> ...
> - we could add oid to union above and lock tables by acquiring lock
> on pg_class with objId.oid = table' oid. Same way we could lock indices
> and whatever we want... if we want -:)
>
As you know well,this implemenation has a flaw that we have
to be anxious about the shortage of shared memory.
> > Lock on tables would give us a restricted solution about pg_class
> > tuples.
> >
> > Thers'a possibility of deadlock in any case but there are few
> > cases when AccessExclusiveLock is really needed and we could
> > acquire an AccessExclusiveLock manually from the first if
> > necessary.
> >
> > I'm not sure about the use of AccessShareLock in parse-analyze-
> > optimize phase however.
>
> There is notion about breakable (parser) locks in Oracle documentation -:)
>
I've known it also but don't know how to realize the similar
concept in PostgreSQL.
Regards.
Hiroshi Inoue