Re: Bad recovery: no pg_xlog/RECOVERYXLOG

On 02/11/17 01:28, Stephen Frost wrote:
> Mark,
>
> * Mark Kirkwood (mark(dot)kirkwood(at)catalyst(dot)net(dot)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.