pg_start_backup and pg_stop_backup Re: [HACKERS] Re:[COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend uponcorrect
in [PgSql]
|
Prev: explicit (void *) casts
Next: pg_start_backup and pg_stop_backup Re: [HACKERS] Re: [COMMITTERS]pgsql: Make CheckRequiredParameterValues() depend upon correct
From: Bruce Momjian on 30 Apr 2010 13:58 Robert Haas wrote: > 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? Well, this email thread mentioned a case where you needed to increase wal_keep_segments to a sufficiently-high value, and of course figuring out such a value is harder than just having a way of turning off recycling with -1. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://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: Bruce Momjian on 30 Apr 2010 14:41 Heikki Linnakangas wrote: > 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? > > Yeah, min_wal_segments or something would make sense. It sounds about as > good or bad as wal_keep_segments to me. I admit I never liked "keep" but couldn't think of better wording. I do like the proposed wording better. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://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: Bruce Momjian on 30 Apr 2010 14:44 Heikki Linnakangas wrote: > Bruce Momjian 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"? > > 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. > > I guess you could move that responsibility to a user-written script, but > we haven't traditionally encouraged or supported people to mess with the > contents of pg_xlog. That would require some more thinking IMHO, not 9.0 > material. > > In practice, you can just set wal_keep_segments to some ridiculously > high value to achieve the same result. Which is where my 'wal_keep_segments = -1' idea came from. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://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: Alvaro Herrera on 30 Apr 2010 14:50 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"? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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: Bruce Momjian on 8 May 2010 22:23
Bruce Momjian wrote: > Simon Riggs 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. > > LOL, good one. > > I assume it was done so it would start with 'wal', but I see > 'max_wal_senders', which doesn't start with 'wal' and would match your > suggestion exactly. I think we should either rename 'wal_keep_segments' > or 'max_wal_senders'. Uh, did we decide that 'wal_keep_segments' was the best name for this GUC setting? I know we shipped beta1 using that name. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://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 |