Josh Berkus <j...@agliodbs.com> writes:
> Since querying pg_locks can be intrusive due to needing to lock the lock
> partitions, when I'm collecting data about locks I generally put a
> statement_timeout on it. However, I'm noticing that this
> statement_timeout appears to be completely ignored; I've seen this query
> run for up to 10 minutes* when the database is heavily loaded. This it
> seems likely to me that the functions under pg_locks aren't checking for
> interrupts. Anybody checked this already?
Whether they do or not, I don't think we allow CHECK_FOR_INTERRUPTS to
trigger while holding an LWLock. So this would not be a trivial thing
to fix.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
