È sicuro annullare una query ALTER TABLE PostgreSQL in attesa di un blocco?

Abbiamo iniziato una ALTER TABLEquery ore fa e solo recentemente ci siamo resi conto (tramite pg_stat_activity) che è in attesa di un blocco. Abbiamo scoperto l'altra query che contiene un blocco sul tavolo che vogliamo modificare e non lasciarlo andare.

La nostra query è una query "semplice" (modifica di un tipo di dati di colonna), ma è in esecuzione su una tabella di grandi dimensioni.

Invece di uccidere il processo che sta trattenendo il blocco, abbiamo deciso che preferiremmo uccidere il ALTER TABLE.

Non abbiamo concluso la ALTER TABLEtransazione.

Per quanto ho capito, il fatto che la nostra query sia in attesa di un blocco significa che è sempre stato in attesa di un blocco e non ha mai cambiato nulla.

È vero? È sicuro per noi annullare definitivamente la nostra ALTER TABLEdomanda? O è possibile che la query abbia già modificato qualcosa e la sua cancellazione lascerebbe il nostro database in uno stato a metà strada di qualche tipo?

PS: il piano è di annullarlo usando SELECT pg_cancel_backend(pid);. Se questa è una cattiva idea, per favore fatemi sapere.

Per quanto ho capito, il fatto che la nostra query sia in attesa di un blocco significa che è sempre stato in attesa di un blocco e non ha mai cambiato nulla.

Giusto - se vedi che pg_stat_activity.waiting è "vero" per un ALTER TABLE, ciò significa quasi sicuramente che sta aspettando pazientemente il blocco ACCESS EXCLUSIVE sulla sua tabella di destinazione e il suo vero lavoro (riscrivendo la tabella se necessario, cambiando i cataloghi , ricostruzione di indici, ecc.) non è ancora iniziata.

È sicuro per noi annullare definitivamente la nostra query ALTER TABLE? O è possibile che la query abbia già modificato qualcosa e la sua cancellazione lascerebbe il nostro database in uno stato a metà strada di qualche tipo?

L'annullamento di query (o, equivalentemente, il rollback di una transazione) in PostgreSQL non presenta alcun rischio di corruzione del database che potresti essere stato spaventato da alcuni altri database (ad esempio l' avvertimento terrificante in fondo a questa pagina). Ecco perché i non utenti super, nelle ultime versioni, sono liberi di usare pg_cancel_backend()e pg_terminate_backend()di uccidere le proprie query in esecuzione su altri back-end: sono sicuri da usare senza preoccuparsi della corruzione del database. Dopotutto, PostgreSQL deve essere pronto a gestire qualsiasi processo venga ucciso, ad esempio SIGKILL dal killer OOM, l'arresto del server, ecc. Ecco a cosa serve il registro WAL .

Potresti anche aver visto che in PostgreSQL è possibile eseguire la maggior parte dei comandi DDL nidificati all'interno di una transazione (multiistruzione), ad es.

BEGIN;
ALTER TABLE foo ...;
ALTER TABLE bar ...;
-- more stuff
COMMIT; -- or ROLLBACK; if you've changed your mind

(fantastico per assicurarsi che le migrazioni dello schema vadano o tutte insieme o per niente.) Hai detto, però:

Non abbiamo concluso la ALTER TABLEtransazione.

Va bene per un singolo comando: dai documenti ,

PostgreSQL in realtà considera ogni istruzione SQL come eseguita all'interno di una transazione. Se non si emette un comando BEGIN, ogni singola istruzione ha un BEGIN implicito e (in caso di successo) COMMIT attorno ad esso. Un gruppo di istruzioni circondato da BEGIN e COMMIT viene talvolta chiamato blocco delle transazioni.

Quindi annullando quello ALTER TABLE, tramite pg_cancel_backend()o un Ctrl-C emesso dal prompt di controllo psql, avrà un effetto simile come se avessi fatto

BEGIN;
ALTER TABLE ... ;
ROLLBACK;

(anche se, come si spera, puoi vedere, l'annullamento di quel costoso ALTER TABLEpuò salvare il database da un sacco di rettifiche inutili se lo fai solo ROLLBACK).

Per approfondire la risposta corretta ed eccellente di Josh:

È sicuro per noi annullare definitivamente la nostra query ALTER TABLE?

Sì.

Sarebbe sicuro anche se fosse nel mezzo di riscrivere il tavolo .

Se lo desideri, puoi semplicemente arrestare l'intero server PostgreSQL, o in effetti la macchina su cui gira, riavviarlo e tutto andrebbe bene. DDL in PostgreSQL è transazionale e sicuro.

Le operazioni DDL vengono registrate tramite WAL ed è garantito che possano essere ripristinate o completate al ripristino dopo un arresto anomalo o l'interruzione.