Re: block-level incremental backup

Поиск
Список
Период
Сортировка
От Ibrar Ahmed
Тема Re: block-level incremental backup
Дата
Msg-id CALtqXTdJxLpD1sg4CHoYD+HsjKzTPuB=HQ=ixreNd3Lw3YnQaA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: block-level incremental backup  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


On Tue, Sep 3, 2019 at 8:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ibrar Ahmed <ibrar.ahmad@gmail.com> writes:
> +1 using the library to tar.

Uh, *what* library?

I was just replying the Robert that he said  

"But I think there must be a reason why tar libraries exist,
and I don't want to write a new one."

I said I am ok to use a library "what he is proposing/thinking", 
but explained to him that TAR is the most simpler format that
why PG has its own code.


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


--
Ibrar Ahmed

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: accounting for memory used for BufFile during hash joins
Следующее
От: Ibrar Ahmed
Дата:
Сообщение: Re: block-level incremental backup