Hi Michael
Thanks for the confirmation. Your rewording removes the confusion. I would
maybe take the opportunity to re-instate that pg_dump cannot be used for PITR,
so in the line of
"These are backups that could be used for point-in-time recovery if
combined with a WAL archive able to recover up to the wanted recovery
point. These backups are typically much faster to backup and restore
than pg_dump for large deployments but can result as well in larger
backup sizes, so the speed of one method or the other is to evaluate
carefully first. Consider also that pg_dump backups cannot be used for
point-in-time recovery."
Maybe the confusion stems from the fact that if you restore a standalone
(self-contained) pg_basebackup then - by default - recovery is done with the
recovery_target immediate option, so if one needs point-in-time recovery he has
to edit the recovery.conf and brings the archives..
Thanks and regards,
Pierre
On Wednesday, June 20, 2018, 5:38:56 AM GMT+2, Michael Paquier
<mich...@paquier.xyz> wrote:
Hi Pierre,
On Tue, Jun 19, 2018 at 12:03:58PM +0000, Pierre Timmermans wrote:
> Here is the doc, the sentence that I find misleading is "There are
> backups that cannot be used for point-in-time recovery", also
> mentioning that they are faster than pg_dumps add to confusion (since
> pg_dumps cannot be used for PITR):
> https://www.postgresql.org/docs/current/static/continuous-archiving.html
Yes, it is indeed perfectly possible to use such backups to do a PITR
as long as you have a WAL archive able to replay up to the point where
you want the replay to happen, so I agree that this is a bit confusing.
This part of the documentation is here since the beginning of times,
well 6559c4a2 to be exact. Perhaps we would want to reword this
sentence as follows:
"These are backups that could be used for point-in-time recovery if
combined with a WAL archive able to recover up to the wanted recovery
point. These backups are typically much faster to backup and restore
than pg_dump for large deployments but can result as well in larger
backup sizes, so the speed of one method or the other is to evaluate
carefully first."
I am open to better suggestions of course.
--
Michael
