From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
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-17 12:43:19 |
Message-ID: | 20050817.214319.41632032.t-ishii@sra.co.jp |
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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Ali Baba | 2005-08-17 12:53:14 | transactions not working properly ? |
Previous Message | Marko Kreen | 2005-08-17 11:22:21 | Re: Upcoming back-branch releases |