Que dois-je faire lorsque pg_cancel_backend ne fonctionne pas?

Si j'ai une requête Postgres de longue durée et que "kill [pid]" normal ne fonctionne pas et que pg_cancel_backend ne fonctionne pas, que dois-je faire?

Vous ne devez jamais tuer -9 aucun processus postgres à moins que votre objectif ne soit de forcer la totalité du serveur. Vous pouvez tuer tout processus qui ne répond pas à un appel pg_cancel_backend () à partir du shell avec

kill <pid>

c'est-à-dire pas -9. Notez que j'ai vu à quelques reprises où même cela n'a pas fonctionné en raison du blocage du processus en attente dans une boucle de données sur une connexion réseau. Si je me souviens bien, tuer le processus client s'est occupé de cela.

http://www.postgresql.org/docs/current/static/server-shutdown.html

pg_cancel_backend équivaut à envoyer SIGINT au processus.
pg_terminate_backend également pour SIGTERM, mais si pg_cancel_backend ne fonctionne pas, je ne vois pas pourquoi pg_terminate_backend le ferait.

Si vous avez essayé ces options, vous pouvez essayer SIGQUIT. Les documents disent: " Ceci n'est recommandé qu'en cas d'urgence. "

(Si vous détestez vos données et espérez qu'elles meurent, vous pouvez utiliser SIGKILL. Mais je ne le ferais pas.)

Vous pouvez utiliser killdirectement ou pg_ctl kill.

si vous avez un Postgres récent, vous pouvez essayer à la pg_terminate_backendplace.

bribles a raison dans sa déclaration ci-dessus ...

SI vous essayez sur SHUTDOWNle serveur, pour moi cependant:

J'essaie simplement de supprimer les bases de données / schémas retirés, qui ont toujours une connexion persistante qu'ils ne lâcheront pas.

Donc, pour répondre à votre question,

Si j'ai une requête Postgres de longue durée ...

pg_cancel_backend ne fonctionne pas ...

que devrais-je faire?

NON LIÉ à l'arrêt du serveur en aucune façon.

J'ai également vu ce comportement de pg_cancel_backend()ne pas fonctionner. Et je voulais partager ma solution de travail.

Je n'ai pas vu de problème jusqu'à présent, avec aucune sorte de "perte" de données.

Encore une fois, je n'essaie pas non plus de supprimer les Activerequêtes.

- Je suis connecté en tant qu'UTILISATEUR "A" avec une session ou un PID de 777777.

- Et va essayer de forcer la déconnexion d'une autre session de l'UTILISATEUR "A" ouvert comme 123456789

- Qui est une connexion en sommeil, et c'est pourquoi je recherche également idledans mes requêtes ci-dessous.

SELECT * 
FROM pg_stat_activity 
WHERE pid = 123456789 
      AND STATE = 'idle';

- Tentative 1

SELECT pg_cancel_backend(pid) 
FROM pg_stat_activity 
WHERE pid = 123456789 
      AND STATE = 'idle';

- Assez intéressant, le résultat indique que l'annulation est VRAIE mais existe toujours.

SELECT * 
FROM pg_stat_activity 
WHERE pid = 123456789 
      AND STATE = 'idle';

- Tentative 2

SELECT pg_terminate_backend(pid) 
FROM pg_stat_activity 
WHERE pid = 123456789 
      AND STATE = 'idle';

- Et maintenant ça n'existe pas ..

SELECT * 
FROM pg_stat_activity 
WHERE pid = 123456789 
      AND STATE = 'idle';

- REMARQUE: J'ai essayé d'utiliser des pid # ridicules pour empêcher les gens de copier-coller et de ruiner leur vie.

- REMARQUE: Par défaut, postgres vous permettra UNIQUEMENT de tuer les processus en cours d'exécution sous VOTRE connexion à USER,

- NOTE: mais vous le saviez déjà.

J'espère que cela t'aides. =)

~ Jay