From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Bad recovery: no pg_xlog/RECOVERYXLOG |
Date: | 2017-11-01 12:28:47 |
Message-ID: | 20171101122847.GS4628@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
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".
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2017-11-01 21:20:51 | Re: Bad recovery: no pg_xlog/RECOVERYXLOG |
Previous Message | Mark Kirkwood | 2017-11-01 08:37:42 | Re: Bad recovery: no pg_xlog/RECOVERYXLOG |