Re: obtaining row locking information

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

In response to

Responses

Browse pgsql-hackers by date

  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