Robert Haas wrote: > On Wed, Oct 27, 2010 at 3:53 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > > On Tue, 2010-10-26 at 22:03 -0400, Robert Haas wrote: > >> On Tue, Oct 26, 2010 at 9:59 PM, Josh Berkus <j...@agliodbs.com> wrote: > >> > > >> >> If you set wal_keep_segments=0, archive_mode=on, and > >> >> archive_command=<something>, you might run out of disk space. > >> >> > >> >> If you set wal_keep_segments=-1, you might run out of disk space. > >> >> > >> >> Are you any more screwed in the second case than you are in the first > >> >> case? > >> > > >> > It is the same to the user either way. ?In either case you have to > >> > change some settings and restart the master. > >> > >> Except that changing wal_keep_segments doesn't require restarting the > >> master. > >> > >> The point of allowing -1 was to allow someone to set it to that value > >> temporarily, to be able to do a hot backup without having to guess how > >> large to set it. ?If you don't have enough disk space for a backup to > >> complete, you're kind of hosed either way. > > > > You're not hosed either way. Fujii designed this carefully to avoid that > > and it works. The case of archive_command failing isn't comparable > > because that is a failure case, not a normal working server. > > > > You don't need to guess the setting of wal_keep_segments. It's a safety > > net that has been deliberately created to avoid the crash that would > > otherwise happen. I've not heard a better proposal, yet, though I too am > > hopeful there is a better one. > > I think you might be confused about what the use case Bruce and I are > imagining, because this doesn't make any sense at all in that context. > The specific use case is that you have archive_mode=off, > wal_level=archive or wal_level=hot_standby, and you want to take a hot > backup. If you do pg_start_backup(), copy the data directory, and do > pg_stop_backup(), you won't necessarily end up with enough xlog to
This is a clear case of protecting people from themselves (make them specify a max wal size), and making the feature easy to use. We can't have both, folks. For 9.0, we picked the former. The same tradeoff often exists for flexibility and ease of use. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
