Promoting sync slave to master without incrementing timeline counter?

Hi all,

Given a cluster of three database servers running 9.1.3 (master, sync slave, async slave), it seems that there are two ways to promote the sync slave to become master:

1. pg_ctl promote the sync slave (increments timeline counter)

2. remove recovery.conf on the sync slave and pg_ctl restart (does not increment timeline counter)

The sync slave becomes master more quickly using `pg_ctl promote`, but now every server in the cluster has to take a new base backup due to the incremented timeline.

2ndQuadrant's repmgr uses the second option so that the async slave can "follow" the new master, saving you from having to do a new base backup.  Additionally, the old master is able to start streaming replication from the new master without a new base backup.  (Repmgr does not actually support the latter behavior out of the box, but it seemed to work.)

So, given a hard failure (i.e. power loss) of the master, `pg_ctl promote` provides availability more quickly, but `pg_ctl restart` provides data redundancy more quickly.  Is this an accurate assessment of the tradeoffs between the two approaches?  I've found talk on the mailings lists surrounding future support for slaves following timelines after a new master completes recovery, but I have been unable to find anything discussing the approach used by repmgr.  Are there  risks associated with the `pg_ctl restart` approach, or is it safe to use?

Cheers,
Dave