Horton

Re: block-level incremental backup

Ibrar Ahmed <ibrar.ahmad@gmail.com>

View thread
From: Ibrar Ahmed <ibrar.ahmad@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>, Jeevan Chalke <jeevan.chalke@enterprisedb.com>, vignesh C <vignesh21@gmail.com>, Anastasia Lubennikova <a.lubennikova@postgrespro.ru>, Stephen Frost <sfrost@snowman.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-09-03T16:44:25Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Don't call data type input functions in GUC check hooks

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