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

From Tom Lane
Subject Re: obtaining row locking information
Date
Msg-id 26400.1124117833@sss.pgh.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  (Tatsuo Ishii <t-ishii@sra.co.jp>)
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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: ohp@pyrenet.fr
Date:
Subject: Re: ALTER INDEX OWNER TO
Next
From: Stephen Frost
Date:
Subject: Re: ALTER ROLES - questions