On Mon, Jun 25, 2012 at 9:19 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Mike Broers <mbroers@gmail.com> wrote:
>
>> Ultimately the hosting service restored the files that they had
>> not brought over during their maintenance migration and we started
>> up ok. So that was a relief.
>
> +1
>
>> We had archived log files but it did not appear that the archive
>> destination was caught up with the xlog the cluster was
>> complaining about.
>>
>> Given that the database server was shut down cleanly, and all
>> other data besides pg_xlog was available as expected (not
>> corrupted), what would have been the problem with pg_resetxlogs?
>
> Frankly, the odds would have been pretty good that you would have
> come up without lost data or a corrupted database; but it's a matter
> of the degree of confidence in that. Startup and shutdown code, by
> its nature, is not exercised as heavily as most PostgreSQL code.
> Startup after using a data recovery utility is even less heavily
> exercised. Less frequently executed code is more likely to have
> subtle bugs which only show up in rare corner cases. I like to
> minimize my risk.
>
> -Kevin
Agreed 100%. Also, this brings up the question of how your server
setup is documented by the hosting providor. If you've got remote
drives, virtual drives or whatever, if needs to be documented there in
such a way they can move you without losing things. Or you'll have to
remind them each time you have a separate mount point that needs to
get transferred, but that's error prone.