On Tue, Aug 9, 2022 at 12:12 PM Magnus Hagander <magnus@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'veput them in replication/basebackup or something like that from the beginning. I'm not sure how much it's worth
doingwrt effects on backpatching etc, but if we're planning to add even more files in the future, the pain will just
becomebigger 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
