Re: Cascaded Replication question

So here are the results of my experiments done yesterday. On absolutely identical configs, the scheme given by me *does not* work on versions 10 and 11, but it works fine from version 12 to 15. Important lines from the C server log:

- for version 10-11:
postgresql-postgres-3-1 | 2023-01-10 15:42:15.922 GMT [32] LOG: restarted WAL streaming at 0/3000000 on timeline 1
postgresql-postgres-3-1 | 2023-01-10 15:42:15.926 GMT [32] LOG: replication terminated by primary server
postgresql-postgres-3-1 | 2023-01-10 15:42:15.926 GMT [32] DETAIL: End of WAL reached on timeline 1 at 0/3000060.

- for versions starting from 12th:
postgresql-postgres-3-1 | 2023-01-10 15:47:29.016 GMT [32] DETAIL: End of WAL reached on timeline 1 at 0/3000060.
postgresql-postgres-3-1 | 2023-01-10 15:47:29.016 GMT [32] LOG: fetching timeline history file for timeline 2 from primary server
postgresql-postgres-3-1 | 2023-01-10 15:47:29.032 GMT [28] LOG: new target timeline is 2
postgresql-postgres-3-1 | 2023-01-10 15:47:29.034 GMT [32] LOG: restarted WAL streaming at 0/3000000 on timeline 2
Experiments were held in Docker Compose environment, hence such logs.
Probably earlier versions require some additional setting adjusted, but at the moment I don't have any idea.
Best regards, Alex Pogodin.

On Monday, January 9, 2023 at 05:24:27 PM GMT+2, Alexander Pogodin <alex_pogodin(at)yahoo(dot)com> wrote:

Hello, guys!
I have a setup with 3 PgSQL instances connected with streaming replication as such:

+---+     +---+     +---+
| A | <-- | B | <-- | C |
+---+     +---+     +---+

When the link to A is broken, I manually promote server B and expect server C to follow new timeline: I have recovery_target_timeline set to latest. But that's not the case. To follow new timeline I have to restart server C. Is it the designed behavior or am I missing something?
I am using the latest 10.x version.

Could you, please, advise?

Best regards, Alex Pogodin.