On 02/11/17 01:28, Stephen Frost wrote:
Mark,
* Mark Kirkwood (mark.kirkwood@xxxxxxxxxxxxxxx) wrote:
While I agree that the scripts concerned would benefit from some
development/qa etc, I'm really disagreeing with your point that folk
'should not do this'. I would like to say that folk 'should do this'
- but try to do it well - and we should help them (isn't that idea
kinda tied up with the whole point of these lists)?
I'm all for someone else starting up a new project to improve the
situation around backups for PG. That not going to be three shell
scripts amounting to maybe 100 lines of code and what I really am
concerned about is people seeing these simple shell scripts thinking
"oh, I'll just use these simple things" without realizing that they're
going to end up in a bad spot because those simple shell scripts aren't
sufficient to do backups with PG properly and reliably.
We could store data in a CSV file and access it through shell scripts
too and call it a database. If someone posted those as an alternative
to PG, I don't doubt that they'd get shot down pretty hard too.
These aren't just perfectionism complaints about shell scripts being
used to do backups of PG either, I've seen people using them and doing
so in ways that result in not having reliable backups which has then
lead to literally days of work be lost.
Put these shell scripts out on a github website with a big "in
development, not for production use, do not use" readme and continue to
hack on them as much as you'd like. Don't post them to these lists with
a "this is how you do backups in PG".
I don't think either the original script author - or myself - are
attempting to suggest a few shell scripts were the next, complete
coverage backup solution (ahem - it is only yourself that is pushing
this extreme interpretation)!
However there is the use case for people that just want a minimal backup
solution that works for their specific environment, and don't want to
bring along a lot of extra machinery that a full coverage
all-singing-and-dancing product includes - this *can* be accomplished by
a few shell scripts. Yes, it does mean that you spend extra time testing
and debugging [1]. Err - I think that is all the original author (who is
probably scared off now), was wanting a bit of help with.
regards
Mark
[1] which is where a pre-existing more complex solution is likely to be
better - it has had more testing in the field, and of course it is fine
to point that out.
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
