pg_start_backup and pg_stop_backup Re: [HACKERS] Re:[COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
in [PgSql]
|
From: Simon Riggs on 28 Apr 2010 14:20 On Wed, 2010-04-28 at 11:11 -0700, Josh Berkus wrote: > > IOW I think that the requirement in pg_start_backup shouldn't be relaxed > > without some more thought/work. > > Yeah, I was talking to Bruce about that this AM, and it seems like a > feature we *need* to have ... for 9.1. > > I'm sufficiently concerned about the amount of flux HS/SR is in right > now that I'd like to declare it "good enough" and move towards release. > Otherwise we'll tinker with it forever and there will be no 9.0. > > "Release early, release often" *is* the OSS mantra, after all. The > question now isn't "Is binary replication perfect" but "is it *good > enough* for some substantial portion of our users". And I think the > answer to the latter question is, at this point, yes. As of exactly today, my answer, for my piece of this is also "yes". I'm not convinced that the same is true across the board. Some important changes have happened in last few days and I see more coming. -- 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: Simon Riggs on 28 Apr 2010 14:34 On Wed, 2010-04-28 at 14:21 -0400, Tom Lane wrote: > Is there any use in looking > at wal_keep_segments as part of this test? I would hope that pg_stop_backup() will have a conditional ERROR message to say ERROR backup inconsistent and cannot be used for SR HINT increase wal_keep_segments or enable archiving for your base backup I think it would also be useful to add a NOTICE to pg_start_backup() NOTICE archiving is not enabled. If we reach exceed wal_keep_segments WAL files then the backup will be invalidated. Expected time for this to happen is X (using linear extrapolation of WAL creation rate since last checkpoint) -- 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: Simon Riggs on 29 Apr 2010 02:16 On Wed, 2010-04-28 at 22:17 +0200, Dimitri Fontaine wrote: > IMO the real fun begins when we talk about multi-slaves support and > their roles (a failover slave wants the master to wait for it to have > applied the WAL before to commit, a reporting slave not so much). So > you'd set the Availability level on each slave and wouldn't commit on > the master until each slave got what it's configured for, or something > like that. Just for the record, I outlined desirable semantics for this on hackers in 2008 and want to keep those ideas on the table. http://archives.postgresql.org/pgsql-hackers/2008-07/msg01001.php My view is that it should be up to the master what happens on master. An additional standby connection should not have the ability to make transactions on the master wait. If we give control to the master rather than the standby, we are then able to allow transactions on the master choose how robust they should be, just as we do with synchronous_commit. IMHO that is extremely important, since we already know that sync rep performs poorly and applications need to mitigate that in some way. Those are the objectives, the parameters to do that are a different story and we might expect much debate. One way of doing this would be to have a parameter called synchronous_replication = N, which would cause the transaction on primary to wait for at least N standbys to reply that they have the data. This would allow settings like synchronous_commit = 0 --async synchronous_commit = 1 --first reply wins == max performance synchronous_commit = 2 --multiple replies needed == max availability .... -- 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: Simon Riggs on 30 Apr 2010 13:44 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. -- 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: Simon Riggs on 30 Apr 2010 14:11
On Fri, 2010-04-30 at 13:58 -0400, Bruce Momjian wrote: > 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. I think the only sensible setting is "as big as my (available) disk space". Any higher and you're going to crash, any lower and you'll invalidate your backup for no reason. -1 emulates current behaviour, BTW Still think we should rename it, in which case 0 is same as "no maximum". -- 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 |