On Sat, Aug 5, 2017 at 4:14 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Sat, Aug 5, 2017 at 5:27 AM, Stephen Frost <sfr...@snowman.net> wrote: >> Unfortunately the day got away from me due to some personal... adventures >> (having to do with lack of air conditioning first and then lack of gas, >> amongst a lot of other things going on right now...). I just got things back >> online but, well, my day tomorrow is pretty well packed solid. I wouldn't >> complain if someone has a few cycles to push these, they look pretty good to >> me but I won't be able to work on PG stuff again until tomorrow night at the >> earliest. > > If no other committer wants to take a shot at those patches, it may be > better to push them after the next minor release happens? I don't like > delaying bug fixes, but the release is close by and time flies.
/me reads patches. 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. - errhint("WAL control functions cannot be executed during recovery."))); + errhint("WAL control functions cannot be executed during recovery; " + "they should be executed on the primary instead"))); I don't agree with this change at all. Executing WAL control functions on the master cannot reasonably be considered equivalent to doing it on the standby. This is like saying "don't take candy from a baby, take it from an adult instead". That could be good advice under the right set of circumstances, but it's also subject to unfortunate misinterpretation. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers