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
|
Список | 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 по дате отправления: