| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(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-03 15:00:22 |
| Message-ID: | 27124.1567522822@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com> writes:
> +1 using the library to tar.
Uh, *what* library?
pg_dump's pg_backup_tar.c is about 1300 lines, a very large fraction
of which is boilerplate for interfacing to pg_backup_archiver's APIs.
The stuff that actually knows specifically about tar looks to be maybe
a couple hundred lines, plus there's another couple hundred lines of
(rather duplicative?) code in src/port/tar.c. None of it is rocket
science.
I can't believe that it'd be a good tradeoff to create a new external
dependency to replace that amount of code. In case you haven't noticed,
our luck with depending on external libraries has been abysmal.
Possibly there's an argument for refactoring things so that there's
more stuff in tar.c and less elsewhere, but let's not go looking
for external code to depend on.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thunder | 2019-09-03 15:22:14 | Got "FATAL: could not access status of transaction" in PG 11.2 |
| Previous Message | Robert Haas | 2019-09-03 14:39:11 | Re: block-level incremental backup |