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