Re: backup manifests - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: backup manifests
Date
Msg-id 20200103170123.GX3195@tamriel.snowman.net
Whole thread Raw
In response to Re: backup manifests  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: backup manifests  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Fri, Jan 3, 2020 at 11:44 AM Stephen Frost <sfrost@snowman.net> wrote:
> > Sure, it'd be work, and for "adding a simple backup manifest", maybe too
> > much to be worth considering ... but that's not what is going on here,
> > is it?  Are we really *just* going to add a backup manifest to
> > pg_basebackup and call it done?  That's not what I understood the goal
> > here to be but rather to start doing a lot of other things with
> > pg_basebackup beyond just having a manifest and if you think just a bit
> > farther down the path, I think you start to realize that you're going to
> > need this base set of capabilities to get to a point where pg_basebackup
> > (or whatever it ends up being called) is able to have the kind of
> > capabilities that exist in other PG backup software already.
>
> I have no development plans for pg_basebackup that require extending
> the format of the manifest file in any significant way, and am not
> aware that anyone else has such plans either. If you are aware of
> something I'm not, or if anyone else is, it would be helpful to know
> about it.

You're certainly intending to do *something* with the manifest, and
while I appreciate that you feel you've come up with a complete use-case
that this simple manifest will be sufficient for, I frankly doubt
that'll actually be the case.  Not long ago it wasn't completely clear
that a manifest at *all* was even going to be necessary for the specific
use-case you had in mind (I'll admit I wasn't 100% sure myself at the
time either), but now that we're down the road of having one, I can't
agree with the blanket assumption that we're never going to want to
extend it, or even that it won't be necessary to add to it before this
particular use-case is fully addressed.

And the same goes for the other things that were discussed up-thread
regarding memory context and error handling and such.

I'm happy to outline the other things that one *might* want to include
in a manifest, if that would be helpful, but I'll also say that I'm not
planning to hack on adding that to pg_basebackup in the next month or
two.  Once we've actually got a manifest, if it's in an extendable
format, I could certainly see people wanting to do more with it though.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: sidewinder has one failure
Next
From: Christoph Berg
Date:
Subject: Re: pgsql: Add basic TAP tests for psql's tab-completion logic.