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.
Regards,
-David
