From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)surnet(dot)cl> |
Cc: | Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_locks view versus prepared transactions |
Date: | 2005-06-20 20:18:03 |
Message-ID: | 22099.1119298683@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)surnet(dot)cl> 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 from the
> ProcArray shared struct, when stats are disabled.
pg_stat_activity is not real time, and should not be because its
intended use is to help interpret the also-not-real-time other
statistics.
If people are concerned about this, my inclination would be to add a
separate view, or just add even more columns to pg_locks?
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 or any such thing into that array.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2005-06-20 20:26:20 | Re: Checkpointing problem with new buffer mgr. |
Previous Message | Tom Lane | 2005-06-20 20:13:39 | Re: pg_locks view versus prepared transactions |