Re: obtaining row locking information

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: alvherre(at)alvh(dot)no-ip(dot)org
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: obtaining row locking information
Date: 2005-08-12 05:08:29
Message-ID: 20050812.140829.59654610.t-ishii@sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message ITAGAKI Takahiro 2005-08-12 06:20:13 Re: Why do index access methods use LP_DELETE?
Previous Message Alvaro Herrera 2005-08-12 03:50:41 Re: obtaining row locking information