From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | pgman(at)candle(dot)pha(dot)pa(dot)us, alvherre(at)alvh(dot)no-ip(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: obtaining row locking information |
Date: | 2005-08-15 14:57:13 |
Message-ID: | 26400.1124117833@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | ohp | 2005-08-15 14:58:30 | Re: ALTER INDEX OWNER TO |
Previous Message | Tatsuo Ishii | 2005-08-15 14:19:31 | Re: obtaining row locking information |