On 18/06/2021 22:55, Jeff Davis wrote:
On Fri, 2021-06-18 at 21:48 +0300, Heikki Linnakangas wrote:
On 18/06/2021 20:27, Jeff Davis wrote:
We could teach it to look into the timeline history to find the
correct
file, though.
That's how recovery_target_timeline behaves, and it would match my
intuition better if START_REPLICATION behaved that way.
If the client asks for a historic timeline, the replication will
stop
when it reaches the end of that timeline. In hindsight, I think it
would
make more sense to send a message to the client to say that it's
switching to a new timeline, and continue streaming from the new
timeline.
Why is it important for the standby to be told explicitly in the
protocol about timeline switches?
So that it knows to write the WAL to the correctly named WAL segment.
You could do it differently, looking at the 'xlp_tli' field in the WAL
page headers, or watching out for checkpoint records that change the
timeline. But currently the standby (and pg_receivewal) depends on the
protocol for that.
If it is important, why only for historical timelines?
Well, the latest timeline doesn't have any timeline switches, by
definition. If you're connected to a standby server, IOW you're doing
cascading replication, then the current timeline can become historic, if
the standby follows a timeline switch. In that case, the replication is
stopped when you reach the timeline switch, just like when you request a
historic timeline.
Hmm, the timeline in the START_REPLICATION command is not specifying
a
recovery target timeline, so I don't think "latest" or "current"
make
much sense there. Per above, it just tells the server which timeline
the
requested starting point belongs to, so it's actually redundant.
That's not very clear from the docs: "if TIMELINE option is specified,
streaming starts on timeline tli...".
Part of the confusion is that there's not a good distinction in
terminology between:
1. a timeline ID, which is a specific segment of a timeline
2. a timeline made up of the given timeline ID and all its
ancestors, terminating at the given ID
3. the timeline made up of the current ID, all ancestor IDs, and all
descendent IDs that the current active primary switches to
4. the set of all timelines that contain a given ID
Agreed, that's a bit confusing.
It seems you are saying that replication only concerns itself with #3,
which does not require a timeline ID at all. That seems basically
correct for now, but since we already document the protocol to take a
timeline, it makes sense to me to just have the primary serve it if
possible.
If we (continue to?) allow timelines for replication, it will start to
treat the primary like an archive. That might not be quite what was
intended, but could be powerful. You could imagine a special archive
that implements the replication protocol, and have replicas directly
off the archive, or maybe doing PITR off the archive.
True.
- Heikki
