Re: relation ### modified while in use

> > 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.

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 -:)

> 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 -:)

Vadim