Re: Automating removal of orphaned stored procedure calls

Поиск
Список
Период
Сортировка
От Holger Jakobs
Тема Re: Automating removal of orphaned stored procedure calls
Дата
Msg-id 17ace17d-eff0-f198-7bbc-74c87957a8ae@jakobs.com
обсуждение исходный текст
Ответ на Automating removal of orphaned stored procedure calls  (John Scalia <jayknowsunix@gmail.com>)
Список pgsql-admin
Am 12.07.22 um 18:58 schrieb John Scalia:
> One of our newer applications is regularly leaving some stored procedures in a partially completed state. It’s not
oneof my applications, and the DBA responsible for it hasn’t said why this happens, but he is trying to automate
removingthese. Currently, it’s a manual process where they log into the db as the application owner which owns these
andremove them manually. For whatever reason he can’t use the application owner’s I’d to run this process. I suggested
addingthe application owner as a group for the actual user he is going to use, and once that happened, using a SET ROLE
tobecome that user, but it did not apparently work. Anybody have any good ideas here to make this work?
 

> Sent from my iPad (How nice you are advertising the device you are using. Is this relevant to your question?)

I cannot see any connection between a transaction "hanging" and the 
usage of stored procedures. Of course it can happen anywhere, if a 
transaction is trying to update rows another transaction has updated 
without having completed.

Try to find out by looking into pg_locks what is happening.

-- 
Holger Jakobs, Bergisch Gladbach, Tel. +49-178-9759012


Вложения

В списке pgsql-admin по дате отправления:

Предыдущее
От: John Scalia
Дата:
Сообщение: Automating removal of orphaned stored procedure calls
Следующее
От: Mladen Gogala
Дата:
Сообщение: Re: Improve "select count(*)" query - takes more than 30 mins for some large tables