On Mon, Apr 6, 2020 at 10:45 AM Stephen Frost <sfr...@snowman.net> wrote: > For my 2c, at least, introducing more shell commands into critical parts > of the system is absolutely the wrong direction to go in. > archive_command continues to be a mess that we refuse to clean up or > even properly document and the project would be much better off by > trying to eliminate it rather than add in new ways for users to end up > with bad or invalid backups. > > Further, having a generic shell script approach like this would result > in things like "well, we don't need to actually add support for X, Y or > Z, because we have this wonderful generic shell script thing and you can > write your own, and therefore we won't accept patches which do add those > capabilities because then we'd have to actually maintain that support." > > In short, -1 from me.
I'm not sure that there's any point in responding to this because I believe that the wording of this email suggests that you've made up your mind that it's bad and that position is not subject to change no matter what anyone else may say. However, I'm going to try on reply anyway, on the theory that (1) I might be wrong and (2) even if I'm right, it might influence the opinions of others who have not spoken yet, and whose opinions may be less settled. First of all, while I agree that archive_command has some problems, I don't think that means that every case where we use a shell command for anything is a hopeless mess. The only problem I really see in this case is that if you route to a local file via an intermediate program you wouldn't get an fsync() any more. But we could probably figure out some clever things to work around that problem, if that's the issue. If there's some other problem, what is it? Second, PostgreSQL is not realistically going to link pg_basebackup against every compression, encryption, and remote storage library out there. One, yeah, we don't want to maintain that. Two, we don't want PostgreSQL to have build-time dependencies on a dozen or more libraries that people might want to use for stuff like this. We might well want to incorporate support for a few of the more popular things in this area, but people will always want support for newer things than what existing server releases feature, and for more of them. Third, I am getting pretty tired of being told every time I try to do something that is related in any way to backup that it's wrong. If your experience with pgbackrest motivated you to propose ways of improving backup and restore functionality in the community, that would be great. But in my experience so far, it seems to mostly involve making a lot of negative comments that make it hard to get anything done. I would appreciate it if you would adopt a more constructive tone. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
