From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net> |
Subject: | Re: where should I stick that backup? |
Date: | 2020-04-08 18:06:12 |
Message-ID: | 20200408180612.GJ13712@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greeitngs,
* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Wed, Apr 8, 2020 at 1:05 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > What if %f.bz2 already exists?
>
> That cannot occur in the scenario I described.
Of course it can.
> > How about if %f has a space in it?
>
> For a tar-format backup I don't think that can happen, because the
> file names will be base.tar and ${tablespace_oid}.tar. For a plain
> format backup it's a potential issue.
I agree that it might not be an issue for tar-format.
> > What
> > about if I'd like to verify that the backup looks reasonably valid
> > without having to find space to store it entirely decompressed?
>
> Then we need to make pg_validatebackup better.
Sure- but shouldn't the design be contemplating how these various tools
will work together?
> > Also, this argument feels disingenuous to me.
> > [ lots more stuff ]
>
> This all just sounds like fearmongering to me. "archive_command
> doesn't work very well, so maybe your thing won't either." Maybe it
> won't, but the fact that archive_command doesn't isn't a reason.
I was trying to explain that we have literally gone down exactly this
path before and it's not been a good result, hence we should be really
careful before going down it again. I don't consider that to be
fearmongering, nor that we should be dismissing that concern out of
hand.
> > Yes, having a storage layer makes a lot of sense here, with features
> > that are understood by the core system and which each driver
> > understands, and then having a filter system which is also pluggable and
> > can support things like compression and hashing for this would also be
> > great.
>
> It's good to know that you prefer a C interface to one based on shell
> scripting. I hope that we will also get some other opinions on that
> question, as my own feelings are somewhat divided (but with some bias
> toward trying to making the shell scripting thing work, because I
> believe it gives a lot more practical flexibility).
Yes, I do prefer a C interface. One might even say "been there, done
that." Hopefully sharing such experience is still useful to do on these
lists.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-04-08 18:09:18 | Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables |
Previous Message | Alvaro Herrera | 2020-04-08 18:01:10 | Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables |