Re: obtaining row locking information

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: obtaining row locking information
Дата
Msg-id 20060321.202402.23031211.t-ishii@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: obtaining row locking information  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: obtaining row locking information  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
I have attached pgrowlocks tested under current.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> Tatsuo, have you developed a new version of this for 8.2?
> 
> ---------------------------------------------------------------------------
> 
> Tatsuo Ishii wrote:
> > > 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
> > 
> 
> -- 
>   Bruce Momjian   http://candle.pha.pa.us
>   SRA OSS, Inc.   http://www.sraoss.com
> 
>   + If your life is a hard drive, Christ can be your backup. +
>

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Pavel Stehule"
Дата:
Сообщение: Re: SQL/XML extension
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: SQL/XML extension