From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> |
Cc: | Rod Taylor <rbt(at)zort(dot)ca>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: lock listing |
Date: | 2002-07-31 22:09:03 |
Message-ID: | 200207312209.g6VM93B26802@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Neil Conway wrote:
> On Wed, Jul 31, 2002 at 03:15:56PM -0400, Rod Taylor wrote:
> > On Wed, 2002-07-31 at 14:47, Neil Conway wrote:
> > > On Wed, Jul 31, 2002 at 02:34:19PM -0400, Bruce Momjian wrote:
> > > > Yes, I think that would be the way to go, or look at the stat functions
> > > > that return tuple sets and use those. That may be a cleaner solution.
>
> [...]
>
> > Lastly, it'll show up in \dS if it's a sudo table. The function is
> > buried in thousands of \df results.
>
> I'm confused: I thought that Bruce was suggesting that I change the
> lock status functions to be similar to the stats functions (i.e. one
> function for every piece of data and a view that pulls them all
> together).
No, sorry, I wasn't suggesting that. Is that how they do it? Yuck. We
well do the table function as soon as Joe has it working 100%. So will
have virtual tables created two ways, one the pg_stat way and the other
the FRS way. Seems fine to me.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2002-07-31 22:24:20 | Re: prepareable statements |
Previous Message | Bruce Momjian | 2002-07-31 22:00:47 | Re: fix pg_dump memory leak |