On Sat, Aug 5, 2017 at 9:11 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> If we apply these patches to 9.6, then pg_stop_backup() on a standby
> will start writing backup history files and removing no-longer-needed
> backup history files. That's a clear behavior change, and it isn't a
> bug fix. Making the waitforarchive option work is a bug fix, but I'm
> not convinced we should take it as a license to change other aspects
> of the behavior in a point release.
After refreshing my memory further, I take it back. pg_stop_backup()
doesn't even have a second argument on v9.6, so back-porting this fix
to 9.6 is a meaningless thing; there's nothing to fix. What the
patches propose to do there instead is adopt the behavior proposed for
v10 when pg_stop_backup()'s second argument is true as the
unconditional behavior in v9.6. For that to be the right thing to do,
we have to decide that the current v9.6 behavior is a bug. But I
(still) think that's very arguable, because the whole point is that
we've just finished adding a flag in v10 to disable on the master the
*very same behavior* we're proposing to mandate on the standby in
v9.6. How can we say that v9.6's current behavior is a bug when v10
produces the same behavior with wait_for_archive = false? That just
doesn't make any sense.
I've pushed a minimal fix for v10 which should address Sawada-san's
original complaint: now, if you say wait_for_archive = true on a
standby, you'll get a warning if it didn't wait, or if archive_mode =
always, it will wait. I think the right thing to do about 9.6 is
document the behavior; there's no problem here that a user can't work
around by doing it right.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
