Re: lock listing

nconway(at)klamath(dot)dyndns(dot)org (Neil Conway) writes:
> On Fri, Jul 19, 2002 at 01:21:10PM -0400, Tom Lane wrote:
>> I'm very unthrilled with this approach to faking up a composite type
>> for pg_show_locks to return.

> As am I, and I agree that the proper long-term answer is some new
> infrastructure for adding builtin SRFs. However, I don't think that's
> a really good reason for rejecting the patch --

I'm not wanting to reject the patch; I'm wanting to restructure it as
additions to lmgr.c plus a contrib module that includes the API function
and perhaps some sample views. The contrib module's install script
could avoid these pesky problems because it can just CREATE a dummy
table or view and then CREATE the function. Once we have a better
answer about declaring built-in SRFs, we can migrate the code into the
core.

>> It seems to me that you could do one palloc, or at most three, while
>> holding the LockMgrLock --- doing three per holderTable entry will take
>> significantly longer.

> Can you elaborate a bit on what changes you'd like to see? Can this
> be done with the data structures I'm using now, or do I need to roll
> my own?

You could get down to 3 pallocs (which is enough of a savings for me)
by creating the workspace as an array of nelements PROCLOCK structs,
an array of nelements PGPROC structs, and an array of nlements LOCK
structs. The intermediate pointer arrays don't seem to buy anything
much except palloc overhead.

>> This seems quite wrong; the active context when the function is called
>> will be a short-term context, which *will* get reset before the next
>> call. Have you tested this with --enable-cassert (which turns on
>> CLOBBER_FREED_MEMORY)? I think you need to switch into a longer-lived
>> context before calling GetLockStatusData.

> Hmmm -- I tested it with '--enable-cassert' and didn't observe any
> problems. I've revised to patch to allocate that long-term memory in
> FuncCallContext.fctx, which I think should be sufficiently long-lived.

Yeah, that's where it should go. I'm puzzled why you didn't observe
a failure ...

regards, tom lane