Add big fat caution to pg_restore docs regards partial db restores

Hi,

Adds a caution to the pg_restore docs....

Against git master.

Karl <kop(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

On Sun, 2012-09-23 at 21:22 -0500, Karl O. Pinc wrote:
> Hi,
>
> Adds a caution to the pg_restore docs....
>
> Against git master.

I'm not sure what you are trying to get at here. It's basically saying,
if you make an incomplete database restore, you might get an incomplete
database. Is there any specific failure scenario that we should
address?

On 11/17/2012 12:27:14 AM, Peter Eisentraut wrote:
> On Sun, 2012-09-23 at 21:22 -0500, Karl O. Pinc wrote:
> > Hi,
> >
> > Adds a caution to the pg_restore docs....
> >
> > Against git master.
>
> I'm not sure what you are trying to get at here. It's basically
> saying,
> if you make an incomplete database restore, you might get an
> incomplete
> database. Is there any specific failure scenario that we should
> address?

Basically, no. It's a reminder of all the various sorts
of inconsistencies that might arise from a partial restore,
not just referential integrity but other integrity constraints
that might be enforced by triggers or the application.
Possibly even manual procedural checks.
The idea is that such a list might direct the attention
of the person doing data recovery to overlooked
integrity issues.

I agree, there's no point in a generic warning.
The warning is only useful if it leads the reader
to do a better job of data recovery.

I would summarize slightly differently, an incomplete
restore can lead to an inconsistent database.

---

One criticism of this patch:

Suggestion for --truncate-tables to pg_restore
https://commitfest.postgresql.org/action/patch_view?id=944

was that because it allowed an incomplete restore
you might get an inconsistent database. If that's
a problem, and at some level it is, then it's a
problem right now and the only
way to address the problem is to help
the data recovery person. I thought some sort
of brief checklist of kinds of data integrity might
help, put someplace where it would be seen when needed.

Feel free to reject. I sent in the patch to
try out the idea. It's a bit crazy, but I didn't
think too crazy to share with the list.

Regards,

Karl <kop(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

On Sat, 2012-11-17 at 12:02 -0600, Karl O. Pinc wrote:
> Feel free to reject. I sent in the patch to
> try out the idea. It's a bit crazy, but I didn't
> think too crazy to share with the list.

I'm going to set this patch as returned with feedback for now. I'm all
for adding more help to the documentation, but I think in this case it
should be more concrete, in the form of, if you have an incomplete
restore, do these steps to verify the integrity of various things. (I
suspect, if users actually encounter the situation you were referring
to, they are pretty much hosed. Transactions are your friend.)

On 12/16/2012 12:51:06 AM, Peter Eisentraut wrote:

> I'm going to set this patch as returned with feedback for now.

Ok. At this point I don't have a vision for improving it
so it might sit there untouched. Maybe someone else
will step forward and make it better.

Regards,

Karl <kop(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein