Re: Small patch to replace 'idle' by 'trans' if transaction is still open

Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
>> There was another thread recently about adding a SHOW command or some
>> such to dump out the state of the lock manager's table in a readable
>> form. I think that'd be a more useful thing to work on than trying
>> to cram one or two bits' worth of info into the ps display.

> Absolutely. I assume from this that the nature and state of all locks are
> stored in shared memory somewhere, and that the data is able to be
> interpreted without reference to non-shared data. If so, this would seem to
> be (a) a very useful thing to have and (b) not too hard. Is that right?

The information is theoretically available in shared memory, but I'm
not sure how hard it is to transform into a conveniently readable form
(like "process X holds locks A, B, and C and is waiting on lock D").
I know that the few times I've tried to grovel around in the lock table
with a debugger, it's been pretty excruciating to figure out what was
going on --- there's just barely enough info there for the code to work,
and no overhead to aid in interpretation. You might find that adding
some additional fields to locktable entries would be a good idea.
(Or maybe not; I can tell you that it's no fun to try to follow it with
just gdb print statements, but a piece of code might not have trouble.)

There already is some code in lock.c to print out the contents of
the table, but it's only conditionally compiled (ifdef LOCK_DEBUG),
has no way to be called except through hand intervention with a debugger,
and furthermore is set up to dump to the backend's stdout, which is
not especially convenient in most scenarios. A first cut would be
to transform that code into a user-callable statement that reports
via elog(NOTICE). Then we could look at the output and see whether
it's useful for mere mortals or not...

regards, tom lane