Re: pg_stop_backup(wait_for_archive := true) on standby server

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stop_backup(wait_for_archive := true) on standby server
Date: 2017-08-14 06:28:17
Message-ID: CAB7nPqTuwqD9UJXJCsQVtJsBcmQiSGmKySFVcA5Jr2DfvQ_dVA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Aug 6, 2017 at 3:22 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> All of (1)-(3) are legitimate user choices, although not everyone will
> make them. (4) is unfortunately the procedure recommended by our
> documentation, which is where the problem comes in. I think it's
> pretty lame that the documentation recommends ignoring the return
> value of pg_stop_backup(); ISTM that it would be very wise to
> recommend cross-checking the return value against the WAL files you're
> keeping for the backup. Even if we thought the waiting logic was
> working perfectly in every case, having a cross-check on something as
> important as backup integrity seems like an awfully good idea.

I would got a little bit more far and say that this is mandatory as
the minimum recovery point that needs to be reached is the LSN
returned by pg_stop_backup(). For backups taken from primaries, this
is a larger deal because XLOG_BACKUP_END may not be present if the
last WAL segment switched is not in the archive. For backups taken
from standbys, the thing is more tricky as the control file should be
backed up last. I would think that the best thing we could do is to
extend pg_stop_backup a bit more so as it returns the control file to
write in the backup using a bytea to hold the data for example.

> I think the root of this problem is that commit
> 7117685461af50f50c03f43e6a622284c8d54694 did only a pretty perfunctory
> update of the documentation, as the commit message itself admits:
>
> Only reference documentation is included. The main section on
> backup still needs
> to be rewritten to cover this, but since that is already scheduled
> for a separate
> large rewrite, it's not included in this patch.
>
> But it doesn't look like that ever really got done.
> https://www.postgresql.org/docs/10/static/continuous-archiving.html#backup-lowlevel-base-backup
> really doesn't talk at all about standbys or differences in required
> procedures between masters and standbys. It makes statements that are
> flagrantly riduculous in the case of a standby, like claiming that
> pg_start_backup() always performs a checkpoint and that pg_stop_backup
> "terminates the backup mode and performs an automatic switch to the
> next WAL segment." Well, obviously not.

Yep.

> And at least to me, that's the real bug here. Somebody needs to go
> through and fix this documentation properly.

So, Magnus? :)
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Arthur Zakirov 2017-08-14 07:46:03 Re: Regressions failures with libxml2 on ArchLinux
Previous Message Michael Paquier 2017-08-14 06:01:44 Re: Regressions failures with libxml2 on ArchLinux