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

From Bruce Momjian
Subject Re: obtaining row locking information
Date
Msg-id 200603210328.k2L3SLE15531@candle.pha.pa.us
Whole thread Raw
In response to Re: obtaining row locking information  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: obtaining row locking information
List pgsql-hackers
Tatsuo, have you developed a new version of this for 8.2?

---------------------------------------------------------------------------

Tatsuo Ishii wrote:
> > 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
> 

--  Bruce Momjian   http://candle.pha.pa.us SRA OSS, Inc.   http://www.sraoss.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] PL/pgSQL: #option select_into_1_row (was SELECT INTO
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] PL/pgSQL: #option select_into_1_row (was SELECT INTO