Re: relation ### modified while in use

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема Re: relation ### modified while in use
Дата
Msg-id 39F63361.82595B26@tpf.co.jp
обсуждение исходный текст
Ответ на RE: relation ### modified while in use  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Список pgsql-hackers

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: how to access backend pid from libpq ?
Следующее
От: Tom Lane
Дата:
Сообщение: Bogus-looking SSL code in postmaster wait loop