1.6 Step | SetupPostgres

Installa PostgreSQL (se assente), lo abilita e lo avvia, in modo reversibile. Vive in src/steps/setup_postgres.rs. Port di setup_postgres di lib/postgres.sh.

È il caso in cui il PreState singolo non basta: PostgreSQL ha tre assi ortogonali di stato, ognuno da ripristinare separatamente (decisione D4).

---

Tre PreState indipendenti

Un solo PreState descriverebbe "PostgreSQL c'è o no"; ma il servizio può essere installato-ma-fermo, attivo-ma-non-abilitato, ecc. Servono tre assi:

struct PostgresSnapshot {
    installed: PreState,  // il pacchetto c'era già?
    enabled:   PreState,  // il servizio era già enabled?
    active:    PreState,  // il servizio era già attivo (running)?
}

Fase	Comportamento
snapshot	per ogni asse: se già vero prima di noi → Preexisting; altrimenti Untracked
run	installa/abilita/avvia solo gli assi Untracked, ognuno → CreatedByUs. Verifica finale: deve risultare active, altrimenti errore
undo	ripristina ogni asse allo stato dello snapshot, in ordine stop → disable → (purge)

---

Undo: ripristino per asse (D4)

L'undo tocca un asse solo se l'avevamo cambiato noi (CreatedByUs). Un servizio che era già attivo/abilitato prima di noi viene lasciato com'era.

Asse	Se CreatedByUs	Se Preexisting
active	systemctl stop	lascia running
enabled	systemctl disable	lascia enabled
installed	vedi sotto (purge gated)	lascia installato

---

Il purge è pericoloso: gated dietro flag (D3-punto2)

Decisione ferma: l'undo di default fa stop + disable (entrambi reversibili) ma NON purga il pacchetto, nemmeno se installed == CreatedByUs.

Il purge di PostgreSQL è troppo distruttivo per un rollback automatico su macchina cliente: potrebbe rimuovere cluster con dati. Stop+disable si annullano; il purge no.

Il purge avviene solo con --aggressive-rollback, e con un avviso esplicito.

TODO (cluster-safety): anche con --aggressive-rollback, prima di purgare andrebbero rilevati best-effort eventuali cluster/DB non-Odoo e, se presenti, declinato il purge con warning. Non ancora implementato in modo affidabile: per ora il purge è gated solo dal flag esplicito — mai senza.

---

Il confine testabile

Servizi (service_is_enabled/is_active/enable/disable/start/stop) e apt sono metodi di SystemOps. Nei test un mock con stato (start/stop aggiornano un flag interno) permette di verificare che la verifica post-start funzioni e che l'undo ripristini gli assi, senza PostgreSQL reale e senza root.

---

Note di design

• La verifica finale (service_is_active) trasforma un avvio fallito in un errore tipizzato, non in un proseguire silenzioso.
• Undo best-effort: ogni azione fallita logga warn e prosegue.
• Test: installato-ma-fermo (avvia→ferma, no disable, no purge), tutto-assente (install+enable+start → stop+disable, no purge), --aggressive-rollback (purga) vs default (no purge), già-attivo (D4: non ferma).