Re: trying again to get incremental backup
От | David Steele |
---|---|
Тема | Re: trying again to get incremental backup |
Дата | |
Msg-id | 937634ae-e562-690a-8a5e-a964ba39f188@pgmasters.net обсуждение исходный текст |
Ответ на | Re: trying again to get incremental backup (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: trying again to get incremental backup
|
Список | pgsql-hackers |
On 10/19/23 12:05, Robert Haas wrote: > On Wed, Oct 4, 2023 at 4:08 PM Robert Haas <robertmhaas@gmail.com> wrote: >> Clearly there's a good amount of stuff to sort out here, but we've >> still got quite a bit of time left before feature freeze so I'd like >> to have a go at it. Please let me know your thoughts, if you have any. > > Apparently, nobody has any thoughts, but here's an updated patch set > anyway. The main change, other than rebasing, is that I did a bunch > more documentation work on the main patch (0005). I'm much happier > with it now, although I expect it may need more adjustments here and > there as outstanding design questions get settled. > > After some thought, I think that it should be fine to commit 0001 and > 0002 as independent refactoring patches, and I plan to go ahead and do > that pretty soon unless somebody objects. 0001 looks pretty good to me. The only thing I find a little troublesome is the repeated construction of file names with/without segment numbers in ResetUnloggedRelationsInDbspaceDir(), .e.g.: + if (segno == 0) + snprintf(dstpath, sizeof(dstpath), "%s/%u", + dbspacedirname, relNumber); + else + snprintf(dstpath, sizeof(dstpath), "%s/%u.%u", + dbspacedirname, relNumber, segno); If this happened three times I'd definitely want a helper function, but even with two I think it would be a bit nicer. 0002 is definitely a good idea. FWIW pgBackRest does this conversion but also errors if it does not succeed. We have never seen a report of this error happening in the wild, so I think it must be pretty rare if it does happen. Regards, -David
В списке pgsql-hackers по дате отправления: