Re: trying again to get incremental backup - Mailing list pgsql-hackers

From Thom Brown
Subject Re: trying again to get incremental backup
Date
Msg-id CAA-aLv7rbnjUqsQYasA1SfHApja8jXU1af_EDFS_RF_mQeXhRQ@mail.gmail.com
Whole thread Raw
In response to Re: trying again to get incremental backup  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: trying again to get incremental backup
List pgsql-hackers
On Wed, 3 Jan 2024 at 15:10, Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Dec 22, 2023 at 12:00 AM Alexander Lakhin <exclusion@gmail.com> wrote:
> My quick experiment shows that that TimestampDifferenceMilliseconds call
> always returns zero, due to it's arguments swapped.

Thanks. Tom already changed the unsigned -> int stuff in a separate
commit, so I just pushed the fixes to PrepareForIncrementalBackup,
both the one I had before, and swapping the arguments to
TimestampDifferenceMilliseconds

I would like to query the following:

--tablespace-mapping=olddir=newdir

    Relocates the tablespace in directory olddir to newdir during the backup. olddir is the absolute path of the tablespace as it exists in the first backup specified on the command line, and newdir is the absolute path to use for the tablespace in the reconstructed backup.

The first backup specified on the command line will be the regular, full, non-incremental backup.  But if a tablespace was introduced subsequently, it would only appear in an incremental backup.  Wouldn't this then mean that a mapping would need to be provided based on the path to the tablespace of that incremental backup's copy?

Regards

Thom

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why don't we support external input/output functions for the composite types
Next
From: Melanie Plageman
Date:
Subject: Re: BitmapHeapScan streaming read user and prelim refactoring