From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
Cc: | t-ishii(at)sra(dot)co(dot)jp, tgl(at)sss(dot)pgh(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: | 2006-04-23 00:21:25 |
Message-ID: | 200604230021.k3N0LPU22142@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii wrote:
> > Tatsuo, are you planning to add this to CVS HEAD?
>
> Yes, I would like to add if there's no objection.
I have heard no comment, and it looks useful, so please add it at your
convenience.
---------------------------------------------------------------------------
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
>
> > ---------------------------------------------------------------------------
> >
> > Tatsuo Ishii wrote:
> > > 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(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
> > > > >
> > > >
> > > > --
> > > > 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. +
> > > >
> >
> > [ Attachment, skipping... ]
> >
> > --
> > Bruce Momjian http://candle.pha.pa.us
> > EnterpriseDB http://www.enterprisedb.com
> >
> > + If your life is a hard drive, Christ can be your backup. +
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2006-04-23 01:13:31 | Re: obtaining row locking information |
Previous Message | Tatsuo Ishii | 2006-04-22 23:24:47 | Re: obtaining row locking information |