| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, 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-09-05 02:07:25 |
| Message-ID: | 20190905020725.GE14853@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Sep 03, 2019 at 08:59:53AM -0400, Robert Haas wrote:
> I think pg_basebackup is using homebrew code to generate tar files,
> but I'm reluctant to do that for reading tar files.
Yes. This code has not actually changed since its introduction.
Please note that we also have code which reads directly data from a
tarball in pg_basebackup.c when appending the recovery parameters to
postgresql.auto.conf for -R. There could be some consolidation here
with what you are doing.
> For generating a
> file, you can always emit the newest and "best" tar format, but for
> reading a file, you probably want to be prepared for older or cruftier
> variants. Maybe not -- I'm not super-familiar with the tar on-disk
> format. But I think there must be a reason why tar libraries exist,
> and I don't want to write a new one.
We need to be sure as well that the library chosen does not block
access to a feature in all the various platforms we have.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-09-05 02:09:35 | Re: pg_promote() can cause busy loop |
| Previous Message | Fujii Masao | 2019-09-05 01:53:19 | Re: pg_promote() can cause busy loop |