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: Fujii Masao on 28 Apr 2010 06:40 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? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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 28 Apr 2010 06:56 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? ....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: Fujii Masao on 28 Apr 2010 08:18 On Wed, Apr 28, 2010 at 8:28 PM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > Or maybe we should check in pg_start_backup() that either archive_mode > or streaming replication (max_wal_senders > 0) is enabled. I agree that pg_start_backup checks not only wal_level but also that. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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 28 Apr 2010 11:10 On Wed, Apr 28, 2010 at 7:22 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > 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. Absolutely, but I'm arguing that we shouldn't change the behavior in the first place. 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. I don't see why we would either (a) break that use case or (b) create another function that does the same thing but with one extra error check. ....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 28 Apr 2010 11:32
Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Which is unfortunate, really. I wish we had a mode where the server > simply refrained from removing/recycling WAL segments while the backup > is running. You could then just: > 1. pg_start_backup() > 2. tar the data directory, except for pg_xlog > 3. tar pg_xlog > 4. pg_stop_backup(). I think there's a termination issue there --- the safe stop point would (appear to be) past whatever WAL you'd copied during step 3. Still, the possibility of adding modes such as this seems to me to be a good argument for not inventing a new version of pg_start_backup/ pg_stop_backup every time. 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 |