Re: Bad recovery: no pg_xlog/RECOVERYXLOG

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

In response to

Responses

Browse pgsql-admin by date

  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