From: | Marc Cousin <cousinmarc(at)gmail(dot)com> |
---|---|
To: | pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: Restauration d'une sauvegarde PITR avec recovery_target_time |
Date: | 2016-06-19 10:53:07 |
Message-ID: | 5c6cdb3d-20d9-b171-9647-74c184a5e86d@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
On 19/06/2016 12:41, Éric de la Musse wrote:
> 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 ;-)).
>
Parce qu'il rejoue le journal du passé vers le futur, et qu'il n'a
l'information qu'une fois arrivé à destination.
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
From | Date | Subject | |
---|---|---|---|
Next Message | Éric de la Musse | 2016-06-19 11:01:05 | Re: Restauration d'une sauvegarde PITR avec recovery_target_time |
Previous Message | Éric de la Musse | 2016-06-19 10:41:33 | Re: Restauration d'une sauvegarde PITR avec recovery_target_time |