I'm going to be testing this. If someone could confirm that this is how writing WAL files works, that being: that it is only considered "done" when the archive_command is done, that would be great.
The archiving of WAL files by the primary does not involve a replication connection of any sort and thus the “WAL sender” settings are not relevant to it; or, here, whether or not you are archiving your WAL is immaterial since you are streaming it as it gets produced.
If you are streaming WAL it seems highly unusual that you’d end up in a situation where the connection goes idle long enough that it gets killed, especially if the backup is still happening. I’d probably go with performing the backup under a disabled (or extremely large?) timeout though and move on to other things.
That isn’t to say I fully understand what actually is happening here…
David J.
