On 2023-Nov-16, Robert Haas wrote: > On Thu, Nov 16, 2023 at 12:23 PM Alvaro Herrera <alvhe...@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)
