J'ai fais un UPDATE malencontreux .... sans la clause where.
Je voudrais donc revenir en arriere, comment faire?
j'ai Postgres 8.2 qui tourne sous freeBSD 6.2
J'ai fais un UPDATE malencontreux .... sans la clause where.
Je voudrais donc revenir en arriere, comment faire?
j'ai Postgres 8.2 qui tourne sous freeBSD 6.2
C possible ca ? Pas sur ...
Non car Postgresql est en autocommit implicite donc si ton update ne faisait pas partie d'un bloc de transaction (begin ... commit/rollback), l'update a été commité par défaut et il est impossible de revenir en arrière (de rollbacker)
Le seul moyen est de repartir d'un ancien dump ou d'une ancienne sauvegarde de ta base, en espérant que tu en as![]()
La théorie, c'est quand on sait tout mais que rien ne fonctionne.
La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !
Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/
Oui, je fais des backup tous les mois/semaines... m'enfin
les logs dans pg_log ne peuvent pas servir à revenir en arriere?
Tes backups sont des dumps (exports), des sauvegardes à froid (copie des fichiers base arrêtée) ou des sauvegardes à chaud (copie des fichiers base ouverte) ?
La théorie, c'est quand on sait tout mais que rien ne fonctionne.
La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !
Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/
Mes backups sont des dumps à chaud, avec des clauses INSERT.
C'est une grosse base, et je n'ai pas trouvé d'autre moyen que d'utiliser des insert (pas assez de RAM pour une restauration d'une base). Mais c'est un autre probleme
Le probleme des insert, c'est que je ne peux pas les utiliser sur l'ancienne base sans effacer les anciennes lignes (car lié par des clef primaires, ce qui effacerait les autre données)... de plus, je ne sais pas si les inserts vont utiliser les mêmes "serial" que lors du dump.
Partager