pg_stop_backup does not complete
in [PgSql]
|
Prev: [HACKERS] pg_stop_backup does not complete
Next: [PATCH] backend: compare word-at-a-time in bcTruelen
From: "Joshua D. Drake" on 24 Feb 2010 13:17 On Wed, 2010-02-24 at 10:07 -0800, Josh Berkus wrote: > Simon, > > 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. Shoot forget the "new users", I am thinking about the hundreds of thousands of existing NOT DBA users. E.g; 90% of our user base. > > 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. Agreed. Although RTFM is important, we shouldn't have RTFM for something that is clearly a user visible behavior mistake on our part. > > > 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. > Basically the reports boil down to people who are actually going to be dealing with this in the field. Simon with respect you have been 6 feet deep in code for too long on this. You need to step back and take some constructive feedback from those that are dealing with the production issues and do so with a smile. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 24 Feb 2010 13:17 On Wed, Feb 24, 2010 at 1:07 PM, Josh Berkus <josh(a)agliodbs.com> wrote: > And, while it makes sense for smart shutdown to wait for > pg_stop_backup(), it does not make sense for fast shutdown to wait. TFM in fact says: http://www.postgresql.org/docs/8.4/static/app-pg-ctl.html#APP-PG-CTL-DESCRIPTION In stop mode, the server that is running in the specified data directory is shut down. Three different shutdown methods can be selected with the -m option: "Smart" mode waits for online backup mode to finish and all the clients to disconnect. This is the default. "Fast" mode does not wait for clients to disconnect and will terminate an online backup in progress. All active transactions are rolled back and clients are forcibly disconnected, then the server is shut down. "Immediate" mode will abort all server processes without a clean shutdown. This will lead to a recovery run on restart. Your OP was not too clear about whether you tried a smart shutdown or a fast shutdown, but if you meant a fast shutdown, this is apparently (he says without testing) a regression. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 24 Feb 2010 13:21 > Your OP was not too clear about whether you tried a smart shutdown or > a fast shutdown, but if you meant a fast shutdown, this is apparently > (he says without testing) a regression. Ah, sorry. Yes, I attempted a fast shutdown. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 24 Feb 2010 13:40 Josh Berkus wrote: > And, while it makes sense for smart shutdown to wait for > pg_stop_backup(), it does not make sense for fast shutdown to wait. Hang on, fast shutdown does *not* wait for backup to finish. > 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. Ahh, that's a detail I missed too. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 24 Feb 2010 13:48
On Wed, 2010-02-24 at 10:07 -0800, Josh Berkus wrote: > > > > 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. No they don't. > 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. I haven't ignored the issue. The behaviour you are complaining about was put there following complaints that it didn't wait. You're ignoring the point that there hasn't been any change in this release and so your comments are unfounded in reality. > 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. :-) I'm told that ignoring user groups is OK... If you're going to address single issues rather than prioritise what is important over what is not, you will get strange responses. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |