Re: pg_stop_backup does not complete

Simon,

> It's not a common setup mistake. Nothing changed in this release and
> this has never been reported before.
>
> The behaviour to wait for pg_stop_backup() was added by user request.
> The behaviour for shutdown to wait for pg_stop_backup() was also added
> by user request.

Your two statements above contradict each other.

And, while it makes sense for smart shutdown to wait for
pg_stop_backup(), it does not make sense for fast shutdown to wait.

Aside from that, the main issue is not having shutdown wait for
pg_stop_backup; it's pg_stop_backup never completing. An issue, I'll
note, you're ignoring. If you're going to be this defensive whenever
anyone reports a bug, it's going to be veeeeeeery slow going to
troubleshoot HS.

As Robert Haas said: "But for sure, if it doesn't, and instead tells the
user to issue pg_stop_backup(), then pg_stop_backup() had better WORK
when the user tries to execute it."

> Your mistake was not typoing an archive_command, it was not correctly
> testing that what you had done was actually working. The fix is to read
> the manual and correct the typo. Shutting down the server after failing
> to configure it is not likely to be a normal reaction to experiencing an
> error in configuration.

The problem is you're thinking of an experienced PostgreSQL DBA doing
setup on a production server. That's not what I'm talking about. I'm
talking about the thousands of new users who are going to try PostgreSQL
for the first time because of HS/SR on a test installation. If they
encounter this issue, they will decide (again) that PostgreSQL is too
hard to use and give up on us for another 5 years.

We've spent the last few years overcoming the image of PostgreSQL being
too complicated for most people to use. You seem hell-bent on restoring
it. Given the timing, our project has one chance to establish a new
reputation as the SQL database for everybody. User-hostile behavior
like this will ruin that chance.

Saying "RTFM and test, you newbie!" is not a valid response, and that's
what your "you should have read the docs" amounts to. Heck, I *did*
read the docs.

> ISTM you should collect test reports, then analyse and prioritise them.
> This rates pretty low for me: low severity, low frequency.

To date, I, Robert Haas, Joe Conway, Josh Drake, and the members of
LAPUG all find this highly problematic behavior. So consider it 6
problem reports, not just one.

--Josh Berkus