Robert,
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Mon, Jul 24, 2017 at 11:40 AM, David Steele <david@pgmasters.net> wrote:
> > Before reviewing the patch, I would note that it looks like this issue was
> > introduced in b6a323a8c before the 9.6 release. The documentation states
> > that the pg_stop_backup() function will wait for all required WAL to be
> > archived, which corresponds to the default in the new patch of
> > waitforarchive = true. The commit notes that the documentation needs
> > updating, but since that didn't happen I think we should consider this a bug
> > in 9.6 and back patch.
> >
> > While this patch brings pg_stop_backup() in line with the documentation, it
> > also introduces a behavioral change compared to 9.6. Currently, the default
> > 9.6 behavior on a standby is to return immediately from pg_stop_backup(),
> > but this patch will cause it to block by default instead. Since action on
> > the master may be required to unblock the process, I see this as a pretty
> > significant change. I still think we should fix and backpatch, but I wanted
> > to point this out.
>
> Hmm. That seems to me like it could break backup scripts that are
> currently working, which seems like a *very* unfriendly thing to do in
> a minor release, especially since 9.6 has no option to override the
> default behavior (nor can we add one, since it would require a change
> to catalog contents).
Those backup scripts might very well be, today, producing invalid
backups though, which would be much less good..
I'd hate to have to do it, but we could technically add a GUC to address
this in the back-branches, no? I'm not sure that's really worthwhile
though..
Thanks!
Stephen
