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: Dimitri Fontaine on 28 Apr 2010 16:17 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > Aidan Van Dyk <aidan(a)highrise.ca> wrote: > >> I'm hoping to be able to build a tool that: >> >> 1) Connects to PG walsender (a la walreceiver) >> 2) Streams WAL from pg master >> 3) Saves WAL into "files" (a la archive)... >> >> i.e. I'm looking to keep a more-up-to-date PITR archive than >> waiting for traditional WAL file archiving... > > I'm interested in that, too. That looks like we have that integrated into walreceiver the day we have cascading support, right? Or maybe we need a special mode of operation where the receiver is (talking to) an archiver. >> I don't personally care about streaming replication replaying WAL >> as it comes, or running queries in recovery... > > I'm with you that far, but I wouldn't want the sender to wait for > remote persistence. That's synchronous replication and its set of synchronicity setting, ranging from sent on the network to the slave, fsync()ed at the slave and applied already on the slave. 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. SyncRep in 9.1 already sounds darn interesting :) Regards, -- dim -- 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 29 Apr 2010 07:11 On Thu, Apr 29, 2010 at 5:38 AM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > NOTICE: WAL archiving is not enabled, you must ensure that all required > WAL segments are streamed or copied through other means to restore the > backup I might think about dropping the words "through other means" from this sentence. ....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 29 Apr 2010 15:33 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Tom Lane wrote: >> Yeah. ISTM the real bottom line here is that we have only a weak grasp >> on how these features will end up being used; or for that matter what >> the common error scenarios will be. I think that for the time being >> we should err on the side of being permissive. We can tighten things >> up and add more nanny-ism in the warnings later on, when we have >> more field experience. > Ok, here's a proposed patch. Per discussion, it relaxes the checks in > pg_start/stop_backup() so that they can be used as long as wal_level >= > 'archive', even if archiving is disabled. This patch seems reasonably noncontroversial (except possibly for message wording, which we can fine-tune later anyway). Please apply. 9.0beta1 is going to get wrapped in only a few hours. BTW, the documentation for these functions might need a bit of adjustment. 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 13:26 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. ....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: Robert Haas on 30 Apr 2010 13:52
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? ....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 |