Re: obtaining row locking information - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: obtaining row locking information
Date
Msg-id 20050817.214319.41632032.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: obtaining row locking information  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: obtaining row locking information  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > To accomplish this I need to add following function into
> > storage/ipc/procarray.c. This is similar to BackendPidGetProc() except
> > that it accepts xid as an argument. Any objection?
> 
> >     if (xid == 0)                /* never match dummy PGPROCs */
> >         return NULL;
> 
> I think this test should be against InvalidTransactionId, not "0", and
> the comment is wrong (you are suppressing matches against idle PGPROCs).
> 
> Also note the comment at the top of the function: once you release
> ProcArrayLock you have no guarantee that the result means anything at
> all; and unlike ProcSendSignal, you have no reason to think that the
> target backend can't quit before you get another cycle.  It might be
> better to return the pid directly rather than assuming it'll still be
> meaningful to indirect through a returned pointer.

Agreed.

> Also, what are you going to do about prepared transactions?  They can
> hold locks but they don't have PIDs.  On the whole, I'm not sure this
> is a good idea at all, because of that.

For prepared transactions, just showing "0" pids are enough, I
think. Assuming that in practice most transactions are not prepared
ones, I think the function is not perfect, but is usefull enough for
most DBAs.
--
Tatsuo Ishii


pgsql-hackers by date:

Previous
From: Marko Kreen
Date:
Subject: Re: Upcoming back-branch releases
Next
From: Andrew Dunstan
Date:
Subject: Re: Upcoming back-branch releases