Improve documentation for wal-g HTTP proxy environment variables #1095
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This stems from a problem that has personally stung me when using spilo and migrating to an architecture that incorporates S3. By setting uppercase
HTTP{S}_PROXY
environment variables in the Spilo docker container I experienced a problem where myarchive_command
command was failing, resulting in the inability to push WAL segments to my S3 bucket (which was only accessible over an HTTP proxy). Despite this, running the exact same command manually from a shell instance inside of the container (wal-g wal-push
) or thepostgres_backup_script.sh
script worked just fine.It took me reading through
configure_spilo.py
to determine that, while other components would function just fine with these uppercase environment variables, wal-g was failing when executed within specific contexts because Spilo was not forwarding them to mywal-e.d/env
folder.While environment variables on Linux are evidently case sensitive, I believe that having this note in the documentation could be a net positive, especially given scenarios where the behaviour is not consistent which makes troubleshooting far harder.