Re: [BUG] pg_basebackup from disconnected standby fails

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: amit(dot)kapila16(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: [BUG] pg_basebackup from disconnected standby fails
Date: 2016-07-21 13:32:08
Message-ID: CAB7nPqSQgt280LtSW9EgX7CvU4JwVraMmOQTM42NM-qyXAkFOw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 21, 2016 at 5:19 PM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> + * minRecoveryPoint can go behind the last checkpoint's redo location when
> + * the checkpoint writes out no buffer. This does no harm to performing a
> + * recovery but such inversion seems inconsistent from the view of the
> + * callers and prevents them from knowing WAL segments needed by sane
> + * calcuation. For the reason we return the last replayed point as the
> + * backup end location. Note that it can be greater than the exact backup
> + * end location or even the minimum recovery point of pg_control at the
> + * time. This is harmless for current uses.

It does not seem an improvement to me to mention a comment regarding
minRecoveryPoint in do_pg_stop_backup, especially knowing that the
patch that we have here uses the last replayed LSN and TLI and does
not care about that anymore.

> AFAICS pg_stop_backup returns a single value of LSN. I don't know
> where this comes from, but the attached patch fixes this and adds
> a mention on the "gap". The original description mentioned
> backup_label and tablespace_map but it seems not necessary. The
> following is the new content rewritten by the patch.

No, this second patch is wrong. This part of the docs refers to
non-exclusive backups, where 3 fields are returned. So the docs are
correct.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2016-07-21 13:49:15 Re: Unexpected memory usage for repeated inserts within plpgsql function
Previous Message Craig Ringer 2016-07-21 13:29:12 Re: PoC: Make it possible to disallow WHERE-less UPDATE and DELETE