Re: pg_stop_backup(wait_for_archive := true) on standby server

On Sat, Aug 5, 2017 at 4:14 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Sat, Aug 5, 2017 at 5:27 AM, Stephen Frost <sfrost(at)snowman(dot)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