Re: Review of pg_rewind

On Wed, Oct 23, 2013 at 2:54 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com>wrote:

> Hi,
>
> Thanks for the feedback. Btw, pg_rewind is not a project included in
> Postgres core as a contrib module or anything, so could you send your
> feedback and the issues you find directly on github instead? The URL
> of the project is https://github.com/vmware/pg_rewind.
>
>
Sure, I will add those issues on github.

> Either way, here are some comments below...
>
> On Wed, Oct 23, 2013 at 6:07 PM, Samrat Revagade
> <revagade(dot)samrat(at)gmail(dot)com> wrote:
> > While testing pg_rewind I encountered following problem.
> > I used following process to do the testing, Please correct me if I am
> doing
> > it in wrong way.
> >
> > Problem-1:
> > pg_rewind gives error (target master must be shut down cleanly.) when
> > master crashed unexpectedly.
> >
> > 1. Setup Streaming Replication (stand alone machine : master server port
> > -5432, standby server port-5433 )
> > 2. Do some operation on master server:
> > postgres=# create table test(id int);
> > 3. Crash the Postgres process of master:
> > kill -9 [pid of postgres process of master server]
> > 4. Promote standby server
> > 5. Run pg_rewind:
> > $ /samrat/postgresql/contrib/pg_rewind/pg_rewind -D
> > /samrat/master-data/ --source-server='host=localhost port=5433
> > dbname=postgres' -v
> > connected to remote server
> > fetched file "global/pg_control", length 8192
> > target master must be shut down cleanly.
> > 6. Check masters control information:
> > $ /samrat/postgresql/install/bin/pg_controldata
> > /samrat/master-data/ | grep "Database cluster state"
> > Database cluster state: in production
> >
> > IIUC It is because pg_rewind does some checks before resynchronizing the
> > PostgreSQL data directories.
> > But In real time scenarios, for example due to hardware failure if master
> > crashed and its controldata shows the state "in production" then
> pg_rewind
> > will fail to pass this check.
> Yeah, you could call that a limitation of this module. When I looked
> at its code some time ago, I had on top of my mind the addition of an
> option of the type --force that could attempt resynchronization of a
> master even if it did not shut down correctly.
>
>
This sounds good :)

Greetings,
Samrat Revagade