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

Mon, 23 Oct 2000 18:23:31 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: relation ### modified while in use


"Mikheev, Vadim" wrote:

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

Yes,I know that "lock table" doesn't touch the correpon
ding pg_class tuple at all.  However isn't it equivalent ?
At least

>
> > > > If we have a mechanism to acquire a share lock on a tuple,we
>

need Access(Share/Exclusive)Lock ?


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

Hmm,I remember you refered to SHARE lock on tuples once.
I wasn't able to suppose how you would implement it then.
I've also thought the enhancement of current locking
machanism which had been used for page level locking but
have always been discouraged by the shmem shortage flaw.

Regards.
Hiroshi Inoue


Tue, 24 Oct 2000 11:09:28 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: relation ### modified while in use
> > > 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).
> >
> 
> Yes,I know that "lock table" doesn't touch the correpon
> ding pg_class tuple at all.  However isn't it equivalent ?

 From what POV?
Lock manager will allow two simultaneous exclusive locks using these
different methods (keys) and so we can interpret (use) them differently.

Vadim



Mon, 23 Oct 2000 22:44:26 -0700
"Vadim Mikheev" <vmikheev@sectorbase.com>
Re: relation ### modified while in use


Vadim Mikheev wrote:

> > > > 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).
> > >
> >
> > Yes,I know that "lock table" doesn't touch the correpon
> > ding pg_class tuple at all.  However isn't it equivalent ?
>
> >From what POV?
> Lock manager will allow two simultaneous exclusive locks using these
> different methods (keys) and so we can interpret (use) them differently.
>

Seems my first explanation was really bad,sorry.

When I saw Access(Share/Exclusive)Lock for the first time,
I thought what they are for.
For VACUUM ? Yes. For DROP TABLE ? Yes. For ALTER TABLE ?
Maybe yes...........
Oracle doesn't have VACUUM and probably handles the other
cases using dictionary lock mechanism.
Unfortunately we've had no dictionary lock mechanism.
Don't Access(..)Lock locks compensate the lack of dictionary
lock mechanism ?

Regards.
Hiroshi Inoue


Wed, 25 Oct 2000 10:12:02 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: relation ### modified while in use