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.
-
-
Replying to @AndresFreundTec @fujii_masao
I agree the new one does not provide easy scriptability. I just don't agree the old one does, or does better.
1 reply 0 retweets 0 likes -
Replying to @magnushagander @fujii_masao
I mean obviously the old interface has issues around the system / script dying in the wrong moment, but I don't understand how having to keep a connection open doesn't increase difficulty.
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec @fujii_masao
It does. Both are difficult to get right. One of them pretends to be easy and in exchange for it you get corrupt backups or a server that doesn't start. The other one is up front about the fact that it's difficult. (and we have an easy one, it's called pg_basebackup)
1 reply 0 retweets 1 like -
And no it's not particularly hard to script with the new interface. Unless it a absolutely has to be in shellscript.
1 reply 0 retweets 0 likes -
Replying to @magnushagander @fujii_masao
Yea, but the reality is that shell-scriptability is a desirable goal, much as we dislike it from a dogmatic position. I think it was a mistake to not make this easier when the new interface was added.
2 replies 0 retweets 0 likes -
Replying to @AndresFreundTec @fujii_masao
TBH, why? Mention a single platform that does shellscript, but does not do say python, perl, ruby, powershell, or any of the scripting languages that actually makes this easier. Why does it have to be shellscript?
1 reply 0 retweets 1 like -
Replying to @magnushagander @fujii_masao
Because of practical reality, it's simply the case that lots of engineers end up writing shell scripts. Partially because it's much more concise, partially because most people speak "some" of it, which isn't the case for the other alternatives you list.
1 reply 0 retweets 0 likes -
We implemented a user hostile design, and we should cop to it. Either argue that the price was worth it, or say that in hindsight it was wrong.
2 replies 0 retweets 3 likes -
Replying to @AndresFreundTec @fujii_masao
I agree that we did, well over 10 years ago. I agree the new one isn't less hostile, and we should provide a less hostile option (actually, we do, in pg_basebackup, but it's also less flexible). But that doesn't mean we should keep around the hostile *and* dangerous option.
1 reply 0 retweets 0 likes
I was&am in favor of dropping the exclusive backup. Just think we ought to also do something to make the scripting of non-exclusive backups easier. Say by having the aforementioned wrapper doing the pg_start/stop_backup and then subshelling to a command, with args, for copying.
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.