On Sat, Aug 5, 2017 at 9:11 AM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
