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: Simon Riggs on 24 Feb 2010 14:02 On Wed, 2010-02-24 at 10:17 -0800, Joshua D. Drake wrote: > 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. I receive constructive feedback all the time from the many users I deal personally and directly with each week. You make the mistake of assuming that someone that can develop has no solution experience. That is exactly how I fund further development, so you are off base by a long way. The way this works currently is based on production feedback. This post is about non-production usage. Until someone comes up with a truly constructive suggestion that takes account of the issues that cause the current design, it won't get traction with me. -- 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 14:04 On 2/24/10 10:40 AM, Heikki Linnakangas wrote: > 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. It did when I tried it. I'll test to see what combination of factors produces that. >> 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. Yeah, that's the important one. I went through the sequence: 1) Try to shut down. 2) be told to run pg_stop_backup() 3) run pg_stop_backup() 4) pg_stop_backup never completes. Look at the original bug report on this thread; it has the details. I think it's still the issue that if no logs are being written (database is idle) pg_stop_backup does not complete, which I thought we fixed, but maybe not? --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: Josh Berkus on 24 Feb 2010 14:07 > 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. I've posted a reproduceable bug (pg_stop_backup never terminating). Either say that you tried to reproduce it and failed, or accept that it exists. Saying "that bug is impossible" is the denial of reality. To reiterate yet again, the problem is that pg_stop_backup never completes. What we do on shutdown is a side issue. --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 14:24 On Wed, 2010-02-24 at 11:07 -0800, Josh Berkus wrote: > > 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. > > I've posted a reproduceable bug (pg_stop_backup never terminating). > Either say that you tried to reproduce it and failed, or accept that it > exists. Saying "that bug is impossible" is the denial of reality. You haven't posted a reproduceable bug, nor is this new to 9.0. You have just noticed a production feature that was specifically put there by user request. The feature exists, has done for some time now and it's acting as it should. This is about what happens in production, not your laptop. The required behaviour in-production is to assume that the sysadmin has configured it correctly and we wait for them to fix the problem. The previous complaints were from people who felt they wanted to avoid invalid backups. Personally, I'd say there were many issues that are new to 9.0 that really are important, and that this isn't one of them. -- 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 14:31
> You haven't posted a reproduceable bug, nor is this new to 9.0. Yes, I have. 1) set up a failing archive_command on an idle database 2) do pg_start_backup 3) do pg_stop_backup 4) pg_stop_backup waits forever (or at least 5 minutes, which as long as I've given it so far). > This is about what happens in production, not your laptop. The required > behaviour in-production is to assume that the sysadmin has configured it > correctly and we wait for them to fix the problem. 90% of our user base does not have a sysadmin. Or, for that matter, even a professional DBA. > The previous > complaints were from people who felt they wanted to avoid invalid > backups. People don't deploy PostgreSQL in production in the first place if it has this kind of "no good option from here" failure when they first try it. HS/SR is for use by new users of PostgreSQL as well as the experienced. --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 |