Re: trying again to get incremental backup
От | Robert Haas |
---|---|
Тема | Re: trying again to get incremental backup |
Дата | |
Msg-id | CA+TgmoYL1vq0Q-Br1uOkgP36Y0r7VfbbqA-XbSB+n=Zhz693=Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: trying again to get incremental backup (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Mon, Nov 20, 2023 at 2:10 PM Robert Haas <robertmhaas@gmail.com> wrote: > > Is this meant to support multiple timelines each with non-overlapping > > adjacent ranges, rather than multiple non-adjacent ranges? > > Correct. I don't see how non-adjacent LSN ranges could ever be a > useful thing, but adjacent ranges on different timelines are useful. Thinking about this a bit more, there are a couple of things we could do here in terms of syntax. Once idea is to give up on having a separate MANIFEST-WAL-RANGE command for each range and instead just cram everything into either a single command: MANIFEST-WAL-RANGES {tli} {startlsn} {endlsn}... Or even into a single option to the BASE_BACKUP command: BASE_BACKUP yadda yadda INCREMENTAL 'tli@startlsn-endlsn,...' Or, since we expect adjacent, non-overlapping ranges, you could even arrange to elide the duplicated boundary LSNs, e.g. MANIFEST_WAL-RANGES {{tli} {lsn}}... {final-lsn} Or BASE_BACKUP yadda yadda INCREMENTAL 'tli@lsn,...,final-lsn' I'm not sure what's best here. Trying to trim out the duplicated boundary LSNs feels a bit like rearrangement for the sake of rearrangement, but maybe it isn't really. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: