Re: backup manifests - Mailing list pgsql-hackers

From Robert Haas
Subject Re: backup manifests
Date
Msg-id CA+TgmoZF0QQAsiO8ckiP2+C=byYDs9_pFmh9=wU9_ournG_Tuw@mail.gmail.com
Whole thread Raw
In response to Re: backup manifests  (David Steele <david@pgmasters.net>)
Responses Re: backup manifests
Re: backup manifests
List pgsql-hackers
On Thu, Mar 26, 2020 at 4:37 PM David Steele <david@pgmasters.net> wrote:
> I agree with Stephen that this should be done, but I agree with you that
> it can wait for a future commit. However, I do think:
>
> 1) It should be called out rather plainly in the documentation.
> 2) If there are files in pg_wal then pg_validatebackup should inform the
> user that those files have not been validated.

I agree with you about #1, and I suspect that there's a way to improve
what I've got here now, but I think I might be too close to this to
figure out what the best way would be, so suggestions welcome.

I think #2 is an interesting idea and could possibly reduce the danger
of user confusion on this point considerably - because, let's face it,
not everyone is going to read the documentation. However, I'm having a
hard time figuring out exactly what we'd print. Right now on success,
unless you specify -q, you get:

[rhaas ~]$ pg_validatebackup  ~/pgslave
backup successfully verified

But it feels strange and possibly confusing to me to print something like:

[rhaas ~]$ pg_validatebackup  ~/pgslave
backup successfully verified (except for pg_wal)

...because there are a few other exceptions too, and also because it
might make the user think that we normally check that but for some
reason decided to skip it in this case. Maybe something more verbose
like:

[rhaas ~]$ pg_validatebackup  ~/pgslave
backup files successfully verified
your backup contains a pg_wal directory, but this tool can't validate
that, so do it yourself

...but that seems a little obnoxious and a little silly to print out every time.

Ideas?

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



pgsql-hackers by date:

Previous
From: Sergei Kornilov
Date:
Subject: Re: allow online change primary_conninfo
Next
From: Tom Lane
Date:
Subject: Re: Reinitialize stack base after fork (for the benefit of rr)?