pg_start_backup and pg_stop_backup Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
in [PgSql]
|
Prev: providing tokenized version of parsed SQL script
Next: pg_start_backup and pg_stop_backup Re: [HACKERS] Re:[COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
From: Robert Haas on 30 Apr 2010 13:53 On Fri, Apr 30, 2010 at 1:39 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > Robert Haas wrote: >> On Fri, Apr 30, 2010 at 12:22 PM, Bruce Momjian <bruce(a)momjian.us> wrote: >> > Tom Lane wrote: >> >> Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: >> >> > Tom Lane wrote: >> >> >> If you aren't archiving then there's no guarantee that you'll still have >> >> >> a continuous WAL series starting from the start of the backup. >> >> >> >> > I wasn't really thinking of this use case, but you could set >> >> > wal_keep_segments "high enough". >> >> >> >> Ah. ?Okay, that seems like a workable approach, at least for people with >> >> reasonably predictable WAL loads. ?We could certainly improve on it >> >> later to make it more bulletproof, but it's usable now --- if we relax >> >> the error checks. >> >> >> >> (wal_keep_segments can be changed without restarting, right?) >> > >> > Should we allow -1 to mean "keep all segments"? >> >> If that's what you want to do, use archive_mode. > > Uh, I assume that will require me to store the WAL files somewhere else, > rather than keeping them in /pg_xlog, which I thought was the goal. Am > I missing something? Well, one of us is. Why would you want to retain all of your WAL logs in pg_xlog forever? ....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: Tom Lane on 30 Apr 2010 14:42 Robert Haas <robertmhaas(a)gmail.com> writes: > On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >> Why is that not called "max_wal_segments"? wal_keep_segments sounds like >> its been through Google translate. > Because it's not a maximum? Indeed. It would really be more like min_wal_segments, if we wanted to name it that way. 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: Robert Haas on 30 Apr 2010 14:45 On Fri, Apr 30, 2010 at 2:08 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Fri, 2010-04-30 at 13:52 -0400, Robert Haas wrote: >> On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >> > On Fri, 2010-04-30 at 12:22 -0400, Bruce Momjian wrote: >> >> > >> >> > (wal_keep_segments can be changed without restarting, right?) >> >> >> >> Should we allow -1 to mean "keep all segments"? >> > >> > Why is that not called "max_wal_segments"? wal_keep_segments sounds like >> > its been through Google translate. >> >> Because it's not a maximum? > > I see the thinking, but why would you ever set it to be something that > is *less* than the existing numbers? That would be pointless and indeed, > does nothing. The only time you touch it at all is when you set it to be > a value higher than the number of files that would normally be kept, and > when that is the case it *will* be the maximum. > > So I say, max_wal_segments = 0 (default) meaning no limit, we just > rotate as needed. We put a comment in the docs to say that if a value is > selected less than 2*checkpoint_segments+1 then the value is overridden. As you were quick to point out to me earlier this week, I am not an expert on our write-ahead logging system; however, I think you are mistaken. Perhaps Heikki could speak to the point more definitively, but I believe that the number of segments that the system retains for WAL archiving or crash recovery is variable. The purpose of this variable is to put a floor under the number of segments that are retained so that SR slaves can catch up if they fall behind. Of course, if archiving is configured, they can do that anyway using restore_command, but you might be running SR without archiving, or you might just want to set this to a small value so that the slaves don't have to keep switching between SR and archive recovery if segments get archived or checkpointed away at inconvenient times. It doesn't make a whole lot of sense to set the floor on the number of segments retained to positive infinity, except in one specific case: archiving is disabled, and you're trying to hang on to enough segments in pg_xlog to take a hot backup. As Tom said, it would be nice to have a more elegant solution to that problem, but we can do that in a future release; it's not really the primary purpose of wal_keep_segments, anyway. It certainly would not be a good idea to make the default configuration "retain all WAL forever". If you did that, a user who sets up PostgreSQL and is not using SR or HS or hot backups will eventually and inevitably fill up their hard disk. ....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: Tom Lane on 30 Apr 2010 14:47 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Bruce Momjian wrote: >> Should we allow -1 to mean "keep all segments"? > Umm, you can't keep all segments around forever, can you? Surely you > have to recycle them sooner or later or you will run out of disk space. You couldn't use that as a permanent setting, but it can make sense as a transient setting, rather than having to guess how much WAL you'll need to keep while setting up a new standby. > In practice, you can just set wal_keep_segments to some ridiculously > high value to achieve the same result. True. 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: Tom Lane on 30 Apr 2010 14:54
Alvaro Herrera <alvherre(a)commandprompt.com> writes: > Bruce Momjian escribi�: >> Which is where my 'wal_keep_segments = -1' idea came from. > Are you suggesting that -1 should mean "keep all segments that fit on > disk, but if creating a new segment fails with ENOSPC, recycle the > oldest one"? No, keep means keep. Even if there were some arguable use for "keep if you can", a scheme like that would render the machine unusable --- everything else on the same filesystem would be falling over. 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 |