Re: obtaining row locking information
От | Tatsuo Ishii |
---|---|
Тема | Re: obtaining row locking information |
Дата | |
Msg-id | 20050817.214319.41632032.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: obtaining row locking information (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: obtaining row locking information
|
Список | 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. 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
В списке pgsql-hackers по дате отправления: