Re: [HACKERS] relation ### modified while in use

[Vadim Mikheev]

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