Cosa devo fare quando pg_cancel_backend non funziona?


8

Se ho una query Postgres di lunga durata e il normale "kill [pid]" non funziona e pg_cancel_backend non funziona, cosa devo fare?

Risposte:


8

Non dovresti mai uccidere -9 qualsiasi processo postgres a meno che il tuo obiettivo non sia quello di abbattere forzatamente l'intero server. È possibile terminare qualsiasi processo che non risponde a una chiamata pg_cancel_backend () dalla shell con

kill <pid>

cioè non -9. Si noti che ho visto alcune volte in cui anche quello non ha funzionato a causa del processo sospeso in attesa in alcuni loop per i dati su una connessione di rete. Se ricordo bene, l'uccisione del processo client si è occupata di questo.


8

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

pg_cancel_backend equivale a inviare SIGINT al processo.
pg_terminate_backend allo stesso modo per SIGTERM, ma se pg_cancel_backend non funziona non vedo perché pg_terminate_backend lo farebbe.

Se hai provato quelle opzioni, potresti provare SIGQUIT. I documenti dicono: " Questo è raccomandato solo in caso di emergenza " .

(Se odi i tuoi dati e speri che muoiano, potresti usare SIGKILL. Ma non lo farei.)

Puoi usare killdirettamente o pg_ctl kill.


+1 PostgreSQL utilizza un processo per connessione, quindi è possibile interrompere un processo senza il pericolo di influire su altre connessioni. Non sono sicuro che ci siano possibilità di corruzione dei dati, ma ne dubito davvero.
David Pashley,

Ho pensato che l'invio di kill -9 a un processo Postgres fosse disastroso, in quanto avrebbe potuto mettere il database in modalità di recupero, il che avrebbe potuto metterlo fuori servizio per molti minuti.


Questo link riguarda l'invio di kill -9 al server . Sto parlando del pid di una singola query. O sono la stessa cosa?

2
@Bribles per favore aggiungi un avviso al tuo post! SIGQUIT provocherà PROBLEMI SERI se provato. L'ho appena fatto e questo ha causato molti problemi: vorrei poter tornare indietro nel tempo e impedirmi di premere il tasto Invio!
ADTC


1

la corruzione è corretta nella sua affermazione sopra ...

Se stai provando al SHUTDOWNserver, per me però:

Sto solo cercando di rimuovere database / schemi in pensione, che hanno ancora una connessione persistente che non lascerà andare.

Quindi, per rispondere alla tua domanda,

Se ho una query Postgres di lunga durata ...

pg_cancel_backend non funziona ...

cosa dovrei fare?

NON CORRELATO allo spegnimento del server in alcun modo.

Ho visto anche questo comportamento di pg_cancel_backend()non funzionare. E volevo condividere la mia soluzione di lavoro.

Finora non ho riscontrato alcun problema, con qualsiasi tipo di "perdita" di dati.

Ancora una volta, non sto nemmeno cercando di uccidere le Activequery.

- Ho effettuato l'accesso come UTENTE "A" con una sessione o PID di 777777.

- E provare a forzare la disconnessione di un'altra sessione dall'UTENTE "A" aperta come 123456789

- Che è una connessione in sospensione, ed è il motivo per cui cerco anche idlenelle mie query di seguito.

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

- Tentativo 1

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

- Risultato abbastanza interessante indica che la cancellazione è VERA ma esiste ancora.

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

- Tentativo 2

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

- E ora non esiste ..

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

- NOTA: ho cercato di usare ridicoli pid # per aiutare a impedire alle persone di copiare, incollare e rovinare la propria vita.

- NOTA: per impostazione predefinita postgres ti consentirà SOLO di interrompere i processi in esecuzione sotto il TUO logging in USER,

- NOTA: ma lo sapevi già.

Spero che sia di aiuto. =)

~ Jay

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.