Przydatne zapytania - lista do ubicia

Czasem pojawia się konieczność ubicia najdłużej wykonujących się zapytań na bazie. Z reguły jest to sytuacja awaryjna i nie ma zbyt wiele czasu, najczęściej chodzi o to by jak najszybciej odzyskać stabilność aplikacji. W takiej sytuacji przydaje się określenie które procesy wykonują najbardziej kosztowne zapytania - te są w kolejności do ubicia. Można to osiągnąć takim oto zapytaniem:

postgres=# SELECT procpid,query_start FROM pg_stat_activity WHERE current_query != '<IDLE>' ORDER BY query_start;
 procpid |          query_start         
---------+-------------------------------
   18422 | 2012-12-24 11:12:15.877034+01
   18434 | 2012-12-24 11:40:36.074373+01
   18394 | 2012-12-24 11:40:36.648773+01
   18261 |
(4 rows)

W tym wypadku podejrzane jest pierwsze z zapytań. Wygląda na bardzo kosztowne obliczeniowo więc jest kandydatem do ubicia. Jeżeli jest na to czas, to wskazana jest weryfikacja jakie to zapytanie zostało wywołane - może być wskazana jego optymalizacja.

postgres=# SELECT current_query FROM pg_stat_activity WHERE procpid = 18422;

Mając tą listę i wiedząc co to za zapytanie można zostaje już tyko ubicie tego konkretnego zapytania. 

postgres=# SELECT pg_cancel_backend(18422);

W wyniku wywołania funkcji pg_cancel_backend() zostanie przerwane tylko zapytanie. Połączenie aplikacji nie zostanie zerwane. To, co aplikacja zrobi już bardzo mocno zależy od tego w czym jest napisana i jak bardzo przewidujących mamy deweloperów.