Re: obtaining row locking information

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgman(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: obtaining row locking information
Date: 2005-08-19 14:42:40
Message-ID: 20050819144240.GC12685@surnet.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 19, 2005 at 09:19:24PM +0900, Tatsuo Ishii wrote:
> > Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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?

I don't think it is critical for it to return valid answers for
subtransactions, but maybe you should add a note in the commentary about
it:

> /*
> * BackendXidGetPid -- get a backend's pid given its XID
> *
> * Returns 0 if not found or it's a prepared transaction. Note that
> * it is up to the caller to be sure that the question remains
> * meaningful for long enough for the answer to be used ...
*
* Only main transaction Ids are considered. This function is mainly
* useful for determining what backend owns a lock.
> */
> int
> BackendXidGetPid(TransactionId xid)
> {

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"The problem with the facetime model is not just that it's demoralizing, but
that the people pretending to work interrupt the ones actually working."
(Paul Graham)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephan Szabo 2005-08-19 15:12:08 Re: [GENERAL] Cascades Failing
Previous Message Tom Lane 2005-08-19 12:57:54 Re: [GENERAL] Cascades Failing