From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Thom Brown <thom(at)linux(dot)com> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: trying again to get incremental backup |
Date: | 2024-04-26 15:32:04 |
Message-ID: | CA+TgmobMhFojKjdh8P=CRVVZkw1bVWrfxfB=drE77T-SgwMLyw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 25, 2024 at 6:44 PM Thom Brown <thom(at)linux(dot)com> wrote:
> 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?
Yes. Tomas Vondra found the same issue, which I have fixed in
1713e3d6cd393fcc1d4873e75c7fa1f6c7023d75.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-04-26 15:55:57 | Re: Why don't we support external input/output functions for the composite types |
Previous Message | Robert Haas | 2024-04-26 15:25:21 | Re: Direct SSL connection with ALPN and HBA rules |