If an exclusive backup API is really removed from #PostgreSQL, new extension supporting an exclusive one may need to be implemented.
-
-
Replying to @fujii_masao
What feature would you actually look for in it? What does that api deliver that the new one doesn't?
1 reply 0 retweets 1 like -
Replying to @magnushagander @fujii_masao
Easy scriptability? Seems to be the only advantage.
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec @fujii_masao
It provides easy scriptable for unsafe scripts. It doesn't provide safe scriptability. We could probably improve a safe scripting interface, but it's not what we had before. Heck even an example of a safe script might help most people.
1 reply 0 retweets 0 likes -
Replying to @magnushagander @fujii_masao
Meh. It's considerably easer to script the new thing wrongly than the old thing. It's far from easy to script keeping a postgres connection open in the background, with proper error checking, than with the old interface. Both are obviously easy to get wrong.
2 replies 0 retweets 0 likes -
If psql's \exec allowed to check for errors it'd be a bit easier. If you want to shell script it, the best bet imo at the moment is to to \exec the copying of the data dir surrounded by start/stop backup. The overall script checks whether copy succeeded by checking a stamp file.
1 reply 0 retweets 0 likes
But that's ridiculous.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.