Re: obtaining row locking information

On Fri, Aug 12, 2005 at 02:08:29PM +0900, Tatsuo Ishii wrote:
> > 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?

Yes. Members are never deleted. This is for two reasons: first, the
transaction could theoretically hold millions of MultiXactId, and we
can't expect it to remember them all; so we don't have a way to find out
which ones it should clean up when it finishes (a process which would be
slow and cumbersome anyway). Second, because the implementation does
not really allow for shrinking (nor enlarging) an array. Once created,
the array is immutable.

If you locked a tuple with transactions B and C; then transaction B
committed; then transaction D locked the tuple again, you would see a
new MultiXactId comprising transactions C and D.

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end." (2nd Commandment for C programmers)