pg_start_backup and pg_stop_backup Re: [HACKERS] Re:[COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
in [PgSql]
|
Prev: pg_start_backup and pg_stop_backup Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Next: pg_start_backup and pg_stop_backup Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
From: Simon Riggs on 28 Apr 2010 06:52 On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote: > On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: > > This doesn't contain any changes to pg_start_backup() yet, that's a > > separate issue and still under discussion. > > I'm thinking of changing pg_start_backup and pg_stop_backup so that > they just check that wal_level >= 'archive', and changing pg_stop_backup > so that it doesn't wait for archiving when archive_mode is OFF. > > This change is very simple and enables us to take a base backup for SR > even if archive_mode is OFF. Thought? Makes sense. I'm wondering whether this could cause problems with people taking hot backups that aren't aimed at SR. Perhaps we could have 2 new functions whose names are more closely linked to the exact purpose: pg_start_replication_copy() etc.. which then act exactly as you suggest. -- 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 07:22 On Wed, 2010-04-28 at 06:56 -0400, Robert Haas wrote: > On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > > On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote: > >> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas > >> <heikki.linnakangas(a)enterprisedb.com> wrote: > >> > This doesn't contain any changes to pg_start_backup() yet, that's a > >> > separate issue and still under discussion. > >> > >> I'm thinking of changing pg_start_backup and pg_stop_backup so that > >> they just check that wal_level >= 'archive', and changing pg_stop_backup > >> so that it doesn't wait for archiving when archive_mode is OFF. > >> > >> This change is very simple and enables us to take a base backup for SR > >> even if archive_mode is OFF. Thought? > > > > Makes sense. > > > > I'm wondering whether this could cause problems with people taking hot > > backups that aren't aimed at SR. Perhaps we could have 2 new functions > > whose names are more closely linked to the exact purpose: > > pg_start_replication_copy() etc.. > > which then act exactly as you suggest. > > Hmm. That seems a bit complicated. Why can't we just let people use > the existing functions the way they always have? We can, but I already gave a reason why we should not. IIRC it was you that suggested changing the names of things if the behaviour changes. -- 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 12:18 On Wed, 2010-04-28 at 11:10 -0400, Robert Haas wrote: > > > > IIRC it was you that suggested changing the names of things if the > > behaviour changes. > > Absolutely, but I'm arguing that we shouldn't change the behavior in > the first place. At least as I understand it... I feel like you're just arguing against whatever I say - your reasoning makes no sense. Masao would not have proposed it as a change if it already worked like that, would he? Just reading the thread would tell you that much. Plus, you clearly don't know how it works now, so not sure why you're commenting at all, its just minor stuff and a few ideas. -- 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: "Joshua D. Drake" on 28 Apr 2010 13:22 On Wed, 2010-04-28 at 12:44 -0400, Robert Haas wrote: > On Wed, Apr 28, 2010 at 11:25 AM, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: > > Robert Haas wrote: > >> At least as I understand it, even when not using > >> archive_mode, streaming replication, or hot standby, it's still > >> perfectly legal to use pg_start_backup() to take a hot backup. > > > > Nope. The correct procedure to take a hot backup is described in > > http://www.postgresql.org/docs/8.4/interactive/continuous-archiving.html#BACKUP-TIPS. > > It involves setting archive_mode=on, and archive_command to a shell > > command that normally just returns true, except when backup is in > > progress. You can't take a hot backup without archiving (or streaming) > > at least temporarily. (except with filesystem-level snapshot capabilities). > > Oh. Well, in that case the proposed change seems reasonable... but > what do you mean by "except with filesystem-level snapshot > capabilities"? Like LVM, SANS or ZFS. Joshua D. Drake > > ...Robert > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering -- 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:08
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. -- 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 |