On 8/9/22 12:34, Robert Haas wrote: > On Tue, Aug 9, 2022 at 12:12 PM Magnus Hagander <magnus@hagander.net> wrote: > >> Anyway, I have no objection. If there'd been that many files, or plans to have it, in the beginning we probably would've put them in replication/basebackup or something like that from the beginning. I'm not sure how much it's worth doing wrt effects on backpatching etc, but if we're planning to add even more files in the future, the pain will just become bigger once we eventually do it... > > Right. > > It's not exactly clear to me what the optimal source code layout is > here. I think the placement here is under src/backend/replication > because the functionality is accessed via the replication protocol, > but I'm not sure if all backup-related code we ever add will be > related to the replication protocol. As a thought experiment, imagine > a background worker that triggers a backup periodically, or a > monitoring view that tells you about the status of your last 10 backup > attempts, or an in-memory hash table that tracks which files have been > modified since the last backup. I'm not planning on implementing any > of those things specifically, but I guess I'm a little concerned that > if we just do the obvious thing of src/backend/replication/backup it's > going to be end up being a little awkward if I or anyone else want to > add backup-related code that isn't specifically about the replication > protocol. > > So maybe src/backend/backup? Or is that too grandiose for the amount > of stuff we have here?
+1 for src/backend/backup. I'd also be happy to see the start/stop code move here at some point.
Yeah, sounds reasonable. There's never an optimal source code layout, but I agree this one is better than putting it under replication.
