RE: relation ### modified while in use

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Philip Warner <pjw(at)rhyme(dot)com(dot)au>, Alex Pilosov <alex(at)pilosoft(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: RE: relation ### modified while in use
Date: 2000-10-24 01:23:31
Message-ID: 8F4C99C66D04D4118F580090272A7A23018D77@SECTORBASE1
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-10-24 01:53:50 TODO updates
Previous Message Hiroshi Inoue 2000-10-24 00:52:19 Re: relation ### modified while in use