On Tue, Jun 15, 2021 at 11:00:57PM -0400, Stephen Frost wrote: > > As I suggested previously- this is similar to the hooks that we provide. We > don’t extensively document them because if you’re writing an extension > which uses a hook, you’re going to be (or should be..) reading the code too.
I disagree, hooks allows developers to implement some new or additional behavior which by definition can't be documented. And it's also relying on the C api which by definition allows you to do anything with the server. There are also of course some requirements but they're quite obvious (like a planner_hook should return a valid plan and such). On the other hand the archive_command is there to do only one clear thing: safely backup a WAL file. And I don't think that what makes that backup "safe" is open to discussion. Sure, you can chose to ignore some of it if you think you can afford to do it, but it doesn't change the fact that it's still a requirement which should be documented. > Consider that, really, an archive command should refuse to allow archiving > of WAL on a timeline which doesn’t have a corresponding history file in the > archive for that timeline (excluding timeline 1). Yes, that's a clear requirement that should be documented. > Also, a backup tool > should compare the result of pg_start_backup to what’s in the control file, > using a fresh read, after start backup returns to make sure that the > storage is sane and not, say, cache’ing pages independently (such as might > happen with a separate NFS mount..). Oh, and if a replica is involved, a > check should be done to see if the replica has changed timelines and an > appropriate message thrown if that happens complaining that the backup was > aborted due to the promotion of the replica… I agree, but unless I'm missing something it's unrelated to what an archive_command should be in charge of?
