On Thu, Nov 25, 2010 at 11:23 AM, Tom Lane wrote:
> Robert Haas writes:
>> No, what I was suggesting was taking the existing function:
>> extern void pgstat_report_waiting(bool waiting);
>> ...and instead doing something like this:
>> extern void pgstat_report_waiting(char *reason);
>> ...and the
Excerpts from Tom Lane's message of jue nov 25 13:23:42 -0300 2010:
> Robert Haas writes:
> > No, what I was suggesting was taking the existing function:
> > extern void pgstat_report_waiting(bool waiting);
> > ...and instead doing something like this:
> > extern void pgstat_report_waiting(char *r
Robert Haas writes:
> No, what I was suggesting was taking the existing function:
> extern void pgstat_report_waiting(bool waiting);
> ...and instead doing something like this:
> extern void pgstat_report_waiting(char *reason);
> ...and then arrange to pass the reason via the eponymous argument.
Alvaro Herrera writes:
> On the other hand, pg_locks is already rather unwieldy to use. We
> already have a self-join that tells us the details of what's locking
> processes: you need to join pg_locks like this:
> ...
> and throw in a bunch of left joins to see the details of database,
> relation
On Thu, Nov 25, 2010 at 10:05 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of jue nov 25 11:56:27 -0300 2010:
>
>> No, what I was suggesting was taking the existing function:
>>
>> extern void pgstat_report_waiting(bool waiting);
>>
>> ...and instead doing something like this:
>
Excerpts from Robert Haas's message of jue nov 25 11:56:27 -0300 2010:
> No, what I was suggesting was taking the existing function:
>
> extern void pgstat_report_waiting(bool waiting);
>
> ...and instead doing something like this:
>
> extern void pgstat_report_waiting(char *reason);
>
> ...an
On Thu, Nov 25, 2010 at 9:00 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mar nov 23 00:08:54 -0300 2010:
>
>> How about publishing additional details to pg_stat_activity via
>> pgstat_report_waiting()?
>
> I'm not sure what you mean here. Are you suggesting we should create
Excerpts from Tom Lane's message of lun nov 22 20:51:09 -0300 2010:
> Alvaro Herrera writes:
> > A much more common ocurrence is tuple locks. We block in an Xid in that
> > case; and this has been a frequent question in the mailing lists and
> > IRC.
>
> > I think it would be very nice to be abl
Excerpts from Robert Haas's message of mar nov 23 00:08:54 -0300 2010:
> How about publishing additional details to pg_stat_activity via
> pgstat_report_waiting()?
I'm not sure what you mean here. Are you suggesting we should create a
new function with that name to report the reason for the lock
On Mon, Nov 22, 2010 at 5:55 PM, Alvaro Herrera wrote:
> Hi,
>
> When we lock on a Xid or VirtualXid, there's no way to obtain clear
> information on the reason for locking. Consider the following example:
>
> CREATE TABLE foo (a int);
>
> Session 1:
> BEGIN;
> SELECT 1;
> -- we now have a snapsh
> ... or maybe not, because when we call XactLockTableWait, we've already
> established that we've accepted to sleep.
>
> Thoughts?
Other than this being a sincere need, no.
--
-- Josh Berkus
PostgreSQL Experts Inc.
Alvaro Herrera writes:
> A much more common ocurrence is tuple locks. We block in an Xid in that
> case; and this has been a frequent question in the mailing lists and
> IRC.
> I think it would be very nice to be able to report something to the
> user; however, I'm not seeing the mechanism.
At
Hi,
When we lock on a Xid or VirtualXid, there's no way to obtain clear
information on the reason for locking. Consider the following example:
CREATE TABLE foo (a int);
Session 1:
BEGIN;
SELECT 1;
-- we now have a snapshot
Session 2:
CREATE INDEX CONCURRENTLY foo_a ON foo(a);
This blocks unti
13 matches
Mail list logo
