> > > 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.
Oracle has no vacuum. We need in AccessExclusiveLock to
support vacuum - to stop any concurrent scans over table.
But maybe I try to make things more complex without
good reason - long term AccessShareLock would just
block vacuum till transaction end (in addition to blocked
concurrent DDL statements we discuss now) - not big
inconvenience probably.
So ok, I have no strong objection against using
Access...Locks as schema 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 ?
No. Access...Locks are acquired over target table
(table' oid is used as key for lmgr hash table),
not over corresponding pg_class tuple, in what case
we would use pg_clas' oid + table' oid as key
(possibility I've described below).
> > > 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)
> >
...
> > - 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.
Didn't you asked about share lock on a tuple?
Share locks may be kept in memory only.
I've just pointed that we have such mechanism -:)
Another possible answer is - Shared Catalog Cache.
Vadim