Skip site navigation (1) Skip section navigation (2)

Re: starting postgres with an empty px_xlog folder

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Mike Broers <mbroers(at)gmail(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: starting postgres with an empty px_xlog folder
Date: 2012-06-25 15:44:31
Message-ID: CAOR=d=34QigJgg57FDgugtrMYZsw53XOhYekBFPjkuFmLZb9Nw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-admin
On Mon, Jun 25, 2012 at 9:19 AM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Mike Broers <mbroers(at)gmail(dot)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.

In response to

pgsql-admin by date

Next:From: 김준철Date: 2012-06-26 02:23:16
Subject: Re: a very slow SQL
Previous:From: Rob CowellDate: 2012-06-25 15:40:48
Subject: replication recovery/startup question

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group