On Tue, Aug 9, 2022 at 12:12 PM Magnus Hagander <mag...@hagander.net> wrote: > Those 11 files are mostly your fault, of course ;)
They are. I tend to prefer smaller source files than many developers, because I find them easier to understand and maintain. If you only include <zlib.h> in basebackup_gzip.c, then you can be pretty sure nothing else involved with basebackup is accidentally depending on it. Similarly with static variables. If you just have one giant file, it's harder to be sure about that sort of thing. > 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? -- Robert Haas EDB: http://www.enterprisedb.com
