Re: [ADMIN] Bad recovery: no pg_xlog/RECOVERYXLOG - Mailing list pgsql-admin
From | Mark Kirkwood |
---|---|
Subject | Re: [ADMIN] Bad recovery: no pg_xlog/RECOVERYXLOG |
Date | |
Msg-id | 4efa2769-78c4-7bf0-5c33-0cf2d942ce74@catalyst.net.nz Whole thread Raw |
In response to | Re: [ADMIN] Bad recovery: no pg_xlog/RECOVERYXLOG (Stephen Frost <sfrost@snowman.net>) |
Responses |
Re: [ADMIN] Bad recovery: no pg_xlog/RECOVERYXLOG
|
List | pgsql-admin |
On 02/11/17 01:28, Stephen Frost wrote: > Mark, > > * Mark Kirkwood (mark.kirkwood@catalyst.net.nz) 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
pgsql-admin by date: