On Tue, Aug 9, 2022 at 6:41 PM David Steele <da...@pgmasters.net> wrote:
> On 8/9/22 12:34, Robert Haas wrote: > > On Tue, Aug 9, 2022 at 12:12 PM Magnus Hagander <mag...@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. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
