Hi
I agree with You!
The most important thing is that the backup is consistent and don't loose any files. However my opinion is that postgresql should raise an error when it find a missing file during recovery, and not try to initialize it with empty pages ....
Thanks to all for the support
Best Regards
Gabriele
Il 12 gennaio 2018 alle 13.52 Alvaro Herrera <alvherre@alvh.no-ip.org> ha scritto:
flumbador@virgilio.it wrote:
I want to show that postgresql, while is recovering the database
applying the WAL file, don't raise any error if it can't find a
missing file. It continue the recovery that end successfully. I know
that the source of the problem is that I have to guarantee that the
backup is complete and consistent but it sound me strange that
postgresql don't signal any errors when it can't find a file .... I
hope that is clear the scope of the testcase.
It seems clear to me. Our current answer is that we just don't check
for this. It seems a very difficult situation to check for -- firstly
because, as you must have realized by now, the recovery process creates
some files that are missing when recovery starts, so just checking "do
all files exist" prior to starting recovery is not the right thing to
check for. Maybe you could figure out a check to run just at the point
where consistent point is reached, but (secondly) that would be a very
expensive way to check for a condition in the "should not happen" camp
(namely, that your backup tool is randomly losing files).
Maybe one thing that is happening is that if you lose a whole file, and
later the recovery process fills page 2 with the correct tuples, then
page 0 and page 1 are initialized too to the empty state as a side effect.
If this is indeed what is happening, I have to say that it's not great.
But again, with a working backup system you wouldn't have lost the file
in the first place, so the case doesn't arise.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services