Hi all
By default, cascading replicas don't follow an upstream's timeline change. I'm not arguing that decision, but as I think it violates POLA somewhat it'd be nice to have an informative message.
Currently the user gets repeating messages like
LOG: restarted WAL streaming at 25/CA000000 on timeline 2
LOG: replication terminated by primary server
DETAIL: End of WAL reached on timeline 2 at 25/CAA66EE8.
which is IMO not super helpful. We'll either continue on the next timeline, or reconnect and see if the server has more to send us on this timeline, depending on the value of recovery_target_timeline. The standby knows what it's doing, and it's not something coming from the upstream like this message seems to say.
But it's not telling the user why it keeps on asking for the same timeline over and over, though it knows perfectly well why.
xlog.c doesn't expose recoveryTargetTLI and recoveryTargetIsLatest so walreceiver.c can't say much about them.
I'm inclined to just add a read-only accessor function for recoveryTargetTLI and recoveryTargetIsLatest that lets the walreceiver look them up.
I'm thinking of something like
recoveryTargetIsLatest || startpointTLI < recoveryTargetTLI ?
errhint("Will look for new timelines on server and restart streaming")
: errhint("recovery_target_timeline limits streaming to timeline %u", startpointTLI)
It's ugly, but it's hard to come up with something succinct and translator-friendly here, especially without duplicating the whole rest of the error message. I can break it out to a simple function if desired.
In the mean time this message and the archives should help people whose cascading replicas decide not to keep up with the times.