OK, the plot thickens. I've been examining the source code to pg_basebackup written by Magnus Hagander. It definitely shows that if you do not issue a "-X f" or "-X s" then the pg_xlogs will NOT be included in the backup. This leads me to a couple more questions:
1) Does anyone know why anything in a WAL segment is required for a database to start? I ask this as the backup_label generated by pg_basebackup indicates a segment where the latest checkpoint is contained. Surely, there has to be some better way to permit the DB to sanely initialize. (Note, I haven't yet examined the sources as to how postgres starts.)
2) If a WAL segment is in fact required for the backed up DB to start, why would pg_basebackup not include those by default? To not do so, doesn't create a backup file, just in this case, a tarball that's worthless. After all, an non-restorable backup, isn't a backup at all.
On Wed, Aug 5, 2015 at 5:00 PM, John Scalia <jayknowsunix@xxxxxxxxx> wrote:
Hi all,We've had a problem surface with the current pg_basebackup procedure we were following. Now, I want to explain that this pre-dates me and I recommended some additional flags to use when running it, specifically I told the group to include "-X f -c fast". Here is the old version they were invoking:pg_basebackup -P -Ft -Z9 -D /var/lib/pgsql/9.2/backups/<date_stamped_backup_filename>The problem we're having, is the tarball these generated will not successfully restore. That is, the tarball looks OK, but the resultant database cannot be started as the pg_xlog directory is empty and postgres says it can't locate the checkpoint segment to sanely initialize.This really doesn't make sense to me. Shouldn't pg_basebackup capture the contents of the pg_xlog directory without needing to use a "-X f" flag? Otherwise, why could pg_basebackup create a "backup" that really is not usable? I'm really just trying to determine why pg_xlog is empty , if it really shouldn't be.--Jay
