Re: block-level incremental backup

Ibrar Ahmed <ibrar.ahmad@gmail.com>

From: Ibrar Ahmed <ibrar.ahmad@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: 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-03T14:04:59Z
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 6:00 PM Robert Haas <robertmhaas@gmail.com> wrote:

> On Sat, Aug 31, 2019 at 3:41 PM Ibrar Ahmed <ibrar.ahmad@gmail.com> wrote:
> > Are we using any tar library in pg_basebackup.c? We already have the
> capability
> > in pg_basebackup to do that.
>
> I think pg_basebackup is using homebrew code to generate tar files,
> but I'm reluctant to do that for reading tar files.  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.
>
+1 using the library to tar. But I think reason not using tar library is
TAR is
one of the most simple file format. What is the best/newest format of TAR?

>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


-- 
Ibrar Ahmed