Re: Let's invent a function to report lock-wait-blocking PIDs

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Greg Smith <greg(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Let's invent a function to report lock-wait-blocking PIDs
Date: 2013-03-25 15:30:39
Message-ID: 20130325153039.GD3699@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Smith wrote:

> Note that an EXPLAIN based approach doesn't solve all the problems
> in this area, because the trickiest ones I run into are ALTER TABLE
> changes--which you can't EXPLAIN. Some API that dumps the locks an
> arbitrary statement acquired just before it exits would be ideal.
> When a user can ask "what locks did an ALTER TABLE adding a foreign
> key take and what order were they grabbed in?", that would solve the
> hardest of the questions I see in the field.

Hm, this sounds like something we could apply to event triggers -- at
ddl_command_end, you would run a SRF, say
pg_event_trigger_acquired_locks() to get what you want.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2013-03-25 15:48:17 Re: pg_dump selectively ignores extension configuration tables
Previous Message Alvaro Herrera 2013-03-25 15:17:35 Re: pg_dump selectively ignores extension configuration tables