Re: obtaining row locking information

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: obtaining row locking information
Дата
Msg-id 20050812.140829.59654610.t-ishii@sra.co.jp
обсуждение исходный текст
Ответ на Re: obtaining row locking information  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: obtaining row locking information  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
> On Fri, Aug 12, 2005 at 12:27:25PM +0900, Tatsuo Ishii wrote:
> 
> > However even one of transactions, for example 647 commits, still it
> > shows as if 647 is a member of muitixid 3.
> > 
> > test=# select * from pgrowlocks('t1');
> >  locked_row | lock_type | locker | multi |   xids    
> > ------------+-----------+--------+-------+-----------
> >       (0,1) | Shared    |      3 | t     | {646,647}
> > (1 row)
> > 
> > Am I missing something?
> 
> By design, a MultiXactId does not change its membership, that is, no
> members are added nor deleted.  When this has to happen (for example a
> row is locked by another backend), a new MultiXactId is generated.  The
> caller is expected to check whether the member transactions are still
> running.

But it seems when members are deleted, new multixid is not
generated. i.e. I see "locker" column does not change. Is this an
expected behavior?
--
Tatsuo Ishii


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: obtaining row locking information
Следующее
От: ITAGAKI Takahiro
Дата:
Сообщение: Re: Why do index access methods use LP_DELETE?