| From: | Éric de la Musse <eric901(at)pouik(dot)org> |
|---|---|
| To: | pgsql-fr-generale(at)postgresql(dot)org |
| Subject: | Re: Restauration d'une sauvegarde PITR avec recovery_target_time |
| Date: | 2016-06-19 10:41:33 |
| Message-ID: | 20160619124133.708cb1cb@archie |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-fr-generale |
Le Sun, 19 Jun 2016 12:16:02 +0200,
Marc Cousin <cousinmarc(at)gmail(dot)com> a écrit :
> En simplifiant un peu, ce que Postgres fait donc, c'est qu'il rejoue
> tout le contenu du journal jusqu'à ce point, et au lieu de commiter
> cette dernière transaction, il l'annule (avec toutes les autres
> transactions encore en cours à ce point), ce qui amène la base à
> l'état «juste avant».
Oui je comprends bien ce qu'il fait. Un peu moins le pourquoi car il
attend une donnée qu'il sait qu'il va pertinemment annuler.
Pourquoi l'attendre alors ? Des contraintes dans l'architecture du
logiciel j'imagine (je n'ai pas les compétences pour aller chercher
la réponse dans le code source ;-)).
Merci pour les explications.
--
Éric de la Musse
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marc Cousin | 2016-06-19 10:53:07 | Re: Restauration d'une sauvegarde PITR avec recovery_target_time |
| Previous Message | Marc Cousin | 2016-06-19 10:16:02 | Re: Restauration d'une sauvegarde PITR avec recovery_target_time |