| From: | Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: block-level incremental backup |
| Date: | 2019-08-29 14:41:04 |
| Message-ID: | CAOgcT0Psa24GJ+Orugat8PiA_Pz3Dam-F0sopZ-fhXoWBeVyuw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Due to the inherent nature of pg_basebackup, the incremental backup also
allows taking backup in tar and compressed format. But, pg_combinebackup
does not understand how to restore this. I think we should either make
pg_combinebackup support restoration of tar incremental backup or restrict
taking the incremental backup in tar format until pg_combinebackup
supports the restoration by making option '--lsn' and '-Ft' exclusive.
It is arguable that one can take the incremental backup in tar format,
extract
that manually and then give the resultant directory as input to the
pg_combinebackup, but I think that kills the purpose of having
pg_combinebackup utility.
Thoughts?
Regards,
Jeevan Ladhe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-08-29 14:50:13 | Re: no mailing list hits in google |
| Previous Message | Alexey Kondratov | 2019-08-29 14:37:45 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |