[Proposal] pg_rewind integration into core

Hi,

It's possible to have a good number of standbys (in the context of async
streaming replication) as part of the client architecture. Rather than
asking the client to look into the intricacies of comparing the LSN of each
standby with that of primary and performing the pg_rewind, isn't it a good
idea to integrate the pg_rewind into the startup logic and perform
pg_rewind on need basis?

Considering the scenarios where primary is ahead of sync standbys, upon
promotion of a standby, pg_rewind is needed on the old primary if it has to
be up as a standby. Similarly in the scenarios where async standbys(in
physical replication context) go ahead of sync standbys, and upon promotion
of a standby, there is need for pg_rewind to be performed on the async
standbys which are ahead of sync standby being promoted.

With these scenarios under consideration, integrating pg_rewind into
postgres core might be a better option IMO. We could optionally choose to
have pg_rewind dry run performed during the standby startup and based on
the need, perform the rewind and have the standby in sync with the primary.

Would like to invite more thoughts from the hackers.

Regards,
RKN