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-02 11:11:41 |
Message-ID: | 20171102111141.GZ4628@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:
> Ok, that is interesting. In my experience, provided the a)
> construction you are using in archive_command correctly reports
> success/failure, and b) you have some monitoring that checks for
> archive failure then that requirement of you having the required
> logs will be fine. Finally that c) your pg_basebackup concoction
> properly checks return codes then you are fine.
>
> All these are reasonably straightforward to implement via shell.
Sure, that'll work much of the time, but that's about like saying that
PG could run without fsync being enabled much of the time and everything
will be ok. Both are accurate, but hopefully you'll agree that PG
really should always be run with fsync enabled.
> Also, if what you are suggesting were actually the case, almost
> everyone's streaming replication (and/or log shipping) would be
> broken all the time.
No, again, this isn't an argument about if it'll work most of the time
or not, it's about if it's correct. PG without fsync will work most of
the time too, but that doesn't mean it's actually correct.
> With respect to 'If I would like to develop etc etc..' - err, all I
> was doing in this thread was helping the original poster make his
> stuff a bit better - I'll continue to do that.
Ignoring the basic requirements which I outlined isn't helping him get
to a reliable backup system.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2017-11-02 11:40:29 | Re: Bad recovery: no pg_xlog/RECOVERYXLOG |
Previous Message | Mark Kirkwood | 2017-11-02 04:23:07 | Re: Bad recovery: no pg_xlog/RECOVERYXLOG |