On 2023-Nov-16, Robert Haas wrote:
> On Thu, Nov 16, 2023 at 12:23 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > I don't understand this point. Currently, the protocol is that
> > UPLOAD_MANIFEST is used to send the manifest prior to requesting the
> > backup. You seem to be saying that you're thinking of removing support
> > for UPLOAD_MANIFEST and instead just give the LSN as an option to the
> > BASE_BACKUP command?
>
> I don't think I'd want to do exactly that, because then you could only
> send one LSN, and I do think we want to send a set of LSN ranges with
> the corresponding TLI for each. I was thinking about dumping
> UPLOAD_MANIFEST and instead having a command like:
>
> INCREMENTAL_WAL_RANGE 1 2/462AC48 2/462C698
>
> The client would execute this command one or more times before
> starting an incremental backup.
That sounds good to me. Not having to parse the manifest server-side
sounds like a win, as does saving the transfer, for the cases where the
manifest is large.
Is this meant to support multiple timelines each with non-overlapping
adjacent ranges, rather than multiple non-adjacent ranges?
Do I have it right that you want to rewrite this bit before considering
this ready to commit?
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"No nos atrevemos a muchas cosas porque son difíciles,
pero son difíciles porque no nos atrevemos a hacerlas" (Séneca)