(there might be a case for having hot_standby=on by default, but I think that got discussed elsewhere and is anyway a different thread).
However, the above does not use replication slots, and if you want to do so, you get:
$ pg_basebackup --pgdata=data2 --write-recovery-conf --slot=pg2 2017-03-19 11:04:37.978 CET [25362] ERROR: replication slot "pg2" does not exist pg_basebackup: could not send replication command "START_REPLICATION": ERROR: replication slot "pg2" does not exist pg_basebackup: child process exited with error 1 pg_basebackup: removing data directory "data2"
The error message is clear enough, but I wonder whether people will start writing streaming replication tutorials just glossing over this because it's one more step to run CREATE_REPLICATION_SLOT manually.
So I propose the attached tiny patch to just create the slot (if it does not exist already) in pg_basebackup, somewhat similar to what pg_receivewal does, albeit unconditionally, if the user explicitly requested a slot:
This would get us somewhat closer to near zero-config replication, in my opinion. Pardon me if that was discussed already and shot down
Comments?
I think this is a good idea, since it makes replication slots easier to use. The change to use temporary slots was good for backups, but didn't help people setting up replicas.
I've been annoyed for a while we didn't have a "create slot" mode in pg_basebackup, but doing it integrated like this is definitely a step even better than that.
I think maybe we should output a message when the slot is created, at least in verbose mode, to make sure people realize that happened. Does that seem reasonable?