Is it mandatory parameter recover_target_timeline=

I have followed below steps for switchover and switchback.

Step 1:- Disconnect application services from 10.x.x.10 and do the following

@Master(10.x.x.10)

pg_ctl -D /DATA_VEC/pgdata stop --mode=fast

@DR(20.x.x.20)

promote DR as read write mode

Step 2:- Start master as DR from new primary

@Master(10.x.x.10) create recovery.conf

standby_mode = 'on'
primary_conninfo = 'user= password= host=20.x.x.20 port=9999
trigger_file = '/tmp/node1'
restore_command = 'cp /DATA_VEC/restore/%f "%p"'

pg_ctl -D /DATA_VEC/pgdata start

after promotion new standby, old primary not getting syncing with new primary server(old standby) Logs from DR server which was primary.

2019-12-01 18:46:56 IST LOG:  database system was shut down in recovery at 2019-12-01 18:46:53 IST
2019-12-01 18:46:56 IST LOG:  entering standby mode
cp: cannot stat `/DATA_VEC/restore/00000002.history': No such file or directory
2019-12-01 18:46:56 IST LOG:
2019-12-01 18:46:56 IST LOG:  restored log file "00000002000000000000000C" from archive
2019-12-01 18:46:57 IST LOG:  consistent recovery state reached at 0/C000090
2019-12-01 18:46:57 IST LOG:  record with zero length at 0/C000090
2019-12-01 18:46:57 IST LOG:  database system is ready to accept read only connections
2019-12-01 18:46:57 IST LOG:  started streaming WAL from primary at 0/C000000 on timeline 2
2019-12-01 18:46:57 IST LOG:  replication terminated by primary server
2019-12-01 18:46:57 IST DETAIL:  End of WAL reached on timeline 2 at 0/C000090.
2019-12-01 18:46:57 IST LOG:  restored log file "00000002000000000000000C" from archive
2019-12-01 18:46:57 IST LOG:  record with zero length at 0/C000090
2019-12-01 18:46:57 IST LOG:  restarted WAL streaming at 0/C000000 on timeline 2
2019-12-01 18:46:57 IST LOG:  replication terminated by primary server
2019-12-01 18:46:57 IST DETAIL:  End of WAL reached on timeline 2 at 0/C000090.

@Master(10.x.x.10)

Pg_xlog content

-bash-4.1$ cd pg_xlog
-bash-4.1$ ll
total 65552
-rw------- 1 postgres postgres      302 Dec  1 12:52 00000002000000000000000A.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  1 13:52 00000002000000000000000B
-rw------- 1 postgres postgres 16777216 Dec  1 14:28 00000002000000000000000C
-rw------- 1 postgres postgres 16777216 Dec  1 12:52 00000002000000000000000D
-rw------- 1 postgres postgres 16777216 Dec  1 12:52 00000002000000000000000E
-rw------- 1 postgres postgres       41 Dec  1 13:57 00000002.history
-rw------- 1 postgres postgres       83 Dec  1 13:57 00000003.history
drwx------ 2 postgres postgres     4096 Dec  1 13:57 archive_status

@in restore_command location content:-

-bash-4.1$ cd /DATA_VEC/restore/ -bash-4.1$ ll total 49156 -rw------- 1 postgres postgres 16777216 Dec 1 18:45 00000002000000000000000A -rw------- 1 postgres postgres 16777216 Nov 30 21:22 00000002000000000000000B -rw------- 1 postgres postgres 16777216 Dec 1 18:45 00000002000000000000000C -rw------- 1 postgres postgres 83 Dec 1 18:45 00000003.history -bash-4.1$

as per_pg_xlog timeline history file 00000003.historyarrived at standby still not starting streaming from new primary.

Question:- 1. Is it mandatory parameter recover_target_timeline='latest' in recovery.conf file" to get latest timeline id from new primary through streaming to start streaming replication?

2.If yes, is it for all PostgreSQL Version? like from 9.3 to 11.5

If you want switch-back functionality, you will have to set recovery_target_timeline='latest', as any promotion will increment the timeline. Using a fixed target timeline is usually reserved for very specific cases (i.e., you need to recover changes after a split-brain, diverged-timeline scenario).

To answer your specific questions: