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: Heikki Linnakangas on 24 Feb 2010 16:41 Josh Berkus wrote: > So I'm seeing pg_abort_backup(), which also produces a > markers which prevent the backup from loading, as an improvement on > current UI. Starting with 9.0, if recovery doesn't see a end-of-backup record, it will refuse to start up. In earlier versions we had a similar mechanism using the backup history files. -- 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: Tom Lane on 24 Feb 2010 16:52 Josh Berkus <josh(a)agliodbs.com> writes: > Thing is, if archive_command is failing, then the backup is useless > regardless until it's fixed. And sending the archives to /dev/null (the > fix you're essentially recommending above) doesn't make the backup any > more useful. So I'm seeing pg_abort_backup(), which also produces a > markers which prevent the backup from loading, as an improvement on > current UI. On reflection I'm not sure what pg_abort_backup would do for you. As Heikki points out, by the time the user has realized that pg_stop_backup() is not completing, it's *already done* all of the state changes it's going to make. There is no way to take the backup-complete WAL entry out of the WAL stream; it's already in there and there's probably ordinary entries after it by now. Having a oh-the-backup-failed-after-all entry somewhere downstream of that is entirely useless; the more so because by the time anything could *see* such an entry, the problem would have been resolved, since the problem is exactly not having gotten the WAL stream out to the archive. Before you could enter pg_abort_backup you'd have to control-C out of the pg_stop_backup call, and that action already accomplishes the only thing pg_abort_backup could do for you. So what I am thinking is that this is really just a minor bit of user unfriendliness in pg_stop_backup. We should address it with one or both of these changes: * emit a NOTICE as soon as pg_stop_backup's actual work is done and it's starting to wait for the archiver (or maybe after it's waited for a few seconds, but much less than the present 60). * extend the existing WARNING (and the NOTICE too if we elect to have one) with a HINT message explicitly saying that you can cancel the wait but thus-and-such consequences might ensue. Both of these things would only be helpful when using client software that shows you received notices promptly. psql is okay, but maybe pgAdmin and other tools would need some further work. There is not much we can do about that in the core project though. regards, tom lane -- 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 16:55 On Wed, 2010-02-24 at 13:30 -0800, Josh Berkus wrote: > So I'm seeing pg_abort_backup(), which also produces a > markers which prevent the backup from loading, as an improvement on > current UI. Since Kevin suggested this in his first post and I agreed with that in the first paragraph of my first post, I think you've wasted a lot of time here going in circles. 42 posts, more than a dozen people. I think we have better things to do than this small issue, which has nothing at all to do with a 9.0 feature. I think you should look at prioritisation. There are many things seriously in need of fixing and this wasn't one of them. Please test the following patch to see if it meets your needs and check the wordings used in the docs. -- Simon Riggs www.2ndQuadrant.com
From: Tom Lane on 24 Feb 2010 17:06 Simon Riggs <simon(a)2ndQuadrant.com> writes: > Please test the following patch to see if it meets your needs and check > the wordings used in the docs. What exactly will that function accomplish, given the assumption that the user already tried pg_stop_backup? regards, tom lane -- 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 17:20
Tom, Simon, > * emit a NOTICE as soon as pg_stop_backup's actual work is done and > it's starting to wait for the archiver (or maybe after it's waited > for a few seconds, but much less than the present 60). > > * extend the existing WARNING (and the NOTICE too if we elect to have > one) with a HINT message explicitly saying that you can cancel the > wait but thus-and-such consequences might ensue. > > Both of these things would only be helpful when using client software > that shows you received notices promptly. psql is okay, but maybe > pgAdmin and other tools would need some further work. There is not > much we can do about that in the core project though. Well, the client software could be fixed in time for 9.0, I'd think. I think that implementing both of the above would probably do the trick for user-friendliness, enough for 9.0. If it's obvious to the user on the console what to do, then they won't panic. > Since Kevin suggested this in his first post and I agreed with that in > the first paragraph of my first post, I think you've wasted a lot of > time here going in circles. 42 posts, more than a dozen people. I think Please tone down the hostility, Simon. I don't think talking about an issue I encountered while testing is a waste of anyone's time, it's how we improve the software. In fact, I'm hoping that potential testers are noticing the drubbing you're getting over this, because belittling anyone's bug reports is not exactly a good way to attract new testers to the project. Further, the multiple posts seem to have arrived at a minimally intrusive solution, so it seems like time well spent. > we have better things to do than this small issue, which has nothing at > all to do with a 9.0 feature. I think you should look at prioritisation. > There are many things seriously in need of fixing and this wasn't one of > them. You've made it clear, repeatedly, that you don't happen to think that new user experience is a priority for 9.0. However, a lot of us on this list disagree with you, and will continue to do so. Priorities are a community decision, not an individual developer one. --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 |