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.

Ok, here is the new version of the function which now checks if the
transactions are still running.

BTW, I think it would be helpfull if the function returns the process
id which runs the transaction. I couldn't find any existing function
which converts an xid to a process id so far, and think inventing
someting like BackendPidGetProc(int pid) would be the way I should
go. Any suggestion?
--
Tatsuo Ishii