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: Robert Haas on 23 Feb 2010 15:14 On Tue, Feb 23, 2010 at 3:09 PM, Joshua D. Drake <jd(a)commandprompt.com> wrote: > On Tue, 2010-02-23 at 14:49 -0500, Robert Haas wrote: > >> > If I issue a shutdown, PostgreSQL should do whatever it needs to do to >> > shutdown; including issuing a pg_stop_backup. >> >> Maybe. 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. > > Right. > >> I gather that the problem is that it has to >> finish all that outstanding archiving before shutting down, in which >> case Kevin's suggestion of having a command to abort the backup seems >> reasonable. I might call it pg_abort_backup() rather than >> pg_fail_backup(), but... >> > > But...? But it seems like a good idea other than that. ....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: Fujii Masao on 23 Feb 2010 19:51 On Wed, Feb 24, 2010 at 4:49 AM, Robert Haas <robertmhaas(a)gmail.com> wrote: > Maybe. 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. I gather that the problem is that it has to > finish all that outstanding archiving before shutting down, in which > case Kevin's suggestion of having a command to abort the backup seems > reasonable. I might call it pg_abort_backup() rather than > pg_fail_backup(), but... Or how about adding new boolean parameter of pg_stop_backup() that specifies whether WAL archiving needs to be waited? pg_stop_backup([wait boolean]) This parameter is optional. If true (default), it waits for archiving. In warm-standby and SR, we don't need to wait for archiving before starting the standby from the base backup. So pg_stop_backup(false) would be useful for speedup of setup of log-shipping. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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 23 Feb 2010 20:46 On 2/23/10 10:58 AM, Simon Riggs wrote: > So I don't see this as something that needs fixing for 9.0. There is > already too much non-essential code there, all of which needs to be > tested. I don't think adding in new corner cases to "help" people makes > any sense until we have automated testing that allows us to rerun the > regression tests to check all this stuff still works. So, you're going to personally field the roughly 10,000 bug reports we get on pgsql-general about this behaviour? 24/7? The fact that we ran into this issue on the *first* day of testing the new alpha4 is indicative of how common it will be -- it is not a corner case, it is a common setup error which will affect probably 20% of new users who try 9.0. And new users are going to panic when they can't shut down postgresql, not just test for issues. Any situation where postgresql cannot be safely shut down because of a common setup mistake (typoing an archive_command) is, IMNSHO, not something we can release with. --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: Simon Riggs on 24 Feb 2010 02:46 On Tue, 2010-02-23 at 17:46 -0800, Josh Berkus wrote: > On 2/23/10 10:58 AM, Simon Riggs wrote: > > So I don't see this as something that needs fixing for 9.0. There is > > already too much non-essential code there, all of which needs to be > > tested. I don't think adding in new corner cases to "help" people makes > > any sense until we have automated testing that allows us to rerun the > > regression tests to check all this stuff still works. > > So, you're going to personally field the roughly 10,000 bug reports we > get on pgsql-general about this behaviour? 24/7? > The fact that we ran into this issue on the *first* day of testing the > new alpha4 is indicative of how common it will be -- it is not a corner > case, it is a common setup error which will affect probably 20% of new > users who try 9.0. And new users are going to panic when they can't > shut down postgresql, not just test for issues. > > Any situation where postgresql cannot be safely shut down because of a > common setup mistake (typoing an archive_command) is, IMNSHO, not > something we can release with. 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 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. Better docs might help you, but I doubt it. ISTM you should collect test reports, then analyse and prioritise them. This rates pretty low for me: low severity, low frequency. (If new users panic when they can't do shutdown the server, they probably won't like smart shutdown very much either.) -- 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
From: Josh Berkus on 24 Feb 2010 13:07
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |