On Mon, Jun 20, 2005 at 04:18:03PM -0400, Tom Lane wrote:
> However, all you could get from ProcArray would be the database in
> which the backend is running, and maybe the owning user's ID if we
> cared to expend the extra space to store it there. We're certainly
> not going to add current_query
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Mon, Jun 20, 2005 at 03:55:45PM -0400, Merlin Moncure wrote:
>> It is interesting to note that systems with stats disabled are unable to
>> get lock owner information in this case (so what?).
> We could make the pg_stat_activity view show information
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> I was also wondering about adding a current-XID column to
>> pg_stat_activity, and encouraging people to join pg_locks and
>> pg_stat_activity on XID instead of PID.
> That would be awesome. Is there any performance penalty to do this?
I gave up on
On Mon, Jun 20, 2005 at 03:55:45PM -0400, Merlin Moncure wrote:
> > Ultimately we should maybe even remove PID from pg_locks, but probably
> > for backwards compatibility it'd have to be deprecated for a release
> > or two first.
>
> It is interesting to note that systems with stats disabled are
> I think the minimum thing we ought to do about this is add an XID
> column to pg_locks to show the transaction ID holding each lock.
> Then you could join that to pg_prepared_xacts to see what's what.
> I was also wondering about adding a current-XID column to
> pg_stat_activity, and encouragin
Now that Heikki's two-phase-commit patch is in, we have a bit of a
problem in the pg_locks view: prepared transactions can hold locks,
but you can't tell which prepared transaction is holding which lock.
They all show with "pid 0". (This should probably come out as a NULL
instead of 0, but I didn'
