Re: Let's invent a function to report lock-wait-blocking PIDs - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Let's invent a function to report lock-wait-blocking PIDs
Date
Msg-id 20130325153039.GD3699@alvh.no-ip.org
Whole thread Raw
In response to Re: Let's invent a function to report lock-wait-blocking PIDs  (Greg Smith <greg@2ndQuadrant.com>)
List 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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pg_dump selectively ignores extension configuration tables
Next
From: Joe Conway
Date:
Subject: Re: pg_dump selectively ignores extension configuration tables