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?
Excerpts from Tom Lane's message of lun nov 22 20:51:09 -0300 2010:
Alvaro Herrera alvhe...@alvh.no-ip.org 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
On Thu, Nov 25, 2010 at 9:00 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
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);
...and then
On Thu, Nov 25, 2010 at 10:05 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
Robert Haas robertmh...@gmail.com 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
Excerpts from Tom Lane's message of jue nov 25 13:23:42 -0300 2010:
Robert Haas robertmh...@gmail.com 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
On Thu, Nov 25, 2010 at 11:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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
Alvaro Herrera alvhe...@alvh.no-ip.org 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
... 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.
On Mon, Nov 22, 2010 at 5:55 PM, Alvaro Herrera alvhe...@alvh.no-ip.org 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
13 matches
Mail list logo
