> 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
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.
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2010-02-24 18:11:10|
|Subject: Re: [BUGS] BUG #4887: inclusion operator (@>) on tsqeries
behaves not conforming to documentation|
|Previous:||From: Boszormenyi Zoltan||Date: 2010-02-24 17:58:31|
|Subject: Re: NaN/Inf fix for ECPG|