This repository was archived by the owner on Mar 19, 2021. It is now read-only.
Some major problems getting postgres backups working.. fixed #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nit() when realpath() returns NULL
joergsteffens
added a commit
that referenced
this pull request
Feb 25, 2016
Some major problems getting postgres backups working.. fixed
Member
|
Looks good. Thank you for the patch. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
Trying to get pgsql-fd working in our setup, I had some major issues that turned out to be bugs, as follows:
The code allows for the possibility that realpath() may return NULL under some circumstances and tries to handle this. But the malloc/free logic was bad, causing a crash. Also, needless duplicate allocation was being done. This has been fixed and cleaned up.
The code was not checking to see if the config file had been successfully opened after getting a backup or restore event. This resulted in a false Success job status with zero length backup in the case of failure to read the file. I have put in a check and returned an M_FATAL JobMessage to prevent this occurrence. Note that this filename is embedded in the FileSet so it's pretty easy for this error to occur.
Thanks!