On Tue, Jun 9, 2015 at 10:56 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > > On Tue, Jun 9, 2015 at 1:04 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Tue, Jun 9, 2015 at 9:09 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > >> > >> On Tue, May 12, 2015 at 10:42 PM, Andrew Dunstan <and...@dunslane.net> > >> wrote: > >> > Map basebackup tablespaces using a tablespace_map file > >> > > >> > Windows can't reliably restore symbolic links from a tar format, so > >> > instead during backup start we create a tablespace_map file, which is > >> > used by the restoring postgres to create the correct links in pg_tblspc. > >> > The backup protocol also now has an option to request this file to be > >> > included in the backup stream, and this is used by pg_basebackup when > >> > operating in tar mode. > >> > > >> > This is done on all platforms, not just Windows. > >> > > >> > This means that pg_basebackup will not not work in tar mode against 9.4 > >> > and older servers, as this protocol option isn't implemented there. > >> > >> While I was performing the recovery-related tests, I found that there was > >> the case where $PGDATA/tablespace_map was not renamed to *.old at the > >> recovery. > >> Is this harmless and intentional? > > > > There shouldn't be any problem because we tablespace_map file > > only if backup file is present. > > > >> Sorry if this has been already > >> discussed so far. > >> > >> The steps to reproduce the problem is: > >> > >> 1. start base backup, i.e., call pg_start_backup(). > >> 2. repeat some write transactions and checkpoints until the WAL file > >> containing > >> the checkpoint record that backup_label indicates will be removed. > >> 3. killall -9 postgres > >> 4. start the server and a crash recovery. > >> > >> At this time, the crash recovery fails with the following error messages. > >> 2015-06-09 12:26:54 JST FATAL: could not locate required checkpoint > >> record > >> 2015-06-09 12:26:54 JST HINT: If you are not restoring from a backup, > >> try removing the file ".../backup_label". > >> > >> 5. according to the above hint message, remove $PGDATA/backup_label > >> and restart a crash recovery > >> > >> Then you can see that tablespace_map remains in $PGDATA after the recovery > >> ends. > >> > > > > The basic idea is that tablespace_map file will be used in case we > > have to restore from a backup which contains tablespaces. So > > I think if user is manually removing backup_label, there is no > > meaning of tablespace_map, so that should also be removed. One > > way to address this is modify the Hint message suggesting that > > remove tablespace_map if present. > > > > Current : > > If you are not restoring from a backup, try removing the file > > \"%s/backup_label\ > > Modify it to: > > If you are not restoring from a backup, try removing the file > > \"%s/backup_label\ > > and, if present \"%s/tablespace_map\. > > Or what about removing tablespace_map file at the beginning of recovery > whenever backup_label doesn't exist?
Yes, thats another way, but is it safe to assume that user won't need that file, I mean in the valid scenario (where both backup_label and tablespace_map are present and usable) also, we rename them to *.old rather than deleting it. Yet another way could be we return error if tablespace_map is present whenever backup_label doesn't exist? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com