From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: A few nuances about specifying the timeline with START_REPLICATION |
Date: | 2021-06-18 21:16:32 |
Message-ID: | 26900d92-ca28-1422-7851-5e18a153e89b@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2021-06-18 21:18:45 | Re: Version reporting in pgbench |
Previous Message | Álvaro Herrera | 2021-06-18 21:05:45 | Re: Race condition in InvalidateObsoleteReplicationSlots() |