Re: [HACKERS] Backup docs

2012-06-17 Thread Magnus Hagander
On Sun, Jun 17, 2012 at 12:13 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
 Magnus Hagander mag...@hagander.net writes:
 This is copied from the old documentation. It used to say It is not
 necessary to be concerned about the amount of time elapsed between
 pg_start_backup and the start of the actual backup, nor between the
 end of the backup and pg_stop_backup.

 And the whole idea was to simplify the text at the beginning ;)

 Oh I see, not your patch to fix then. I just quick read the diff, as you
 can see.

 This is copied exactly from what it is today. I'm sure it can be
 approved, but it's not the goal of this patch. Let's not let
 perfection get in the way of improvement...

 Same.

 It does, it's under standalone hot backups. The second to last part
 of the patch.

 Perfect then.

 Sorry for the noise, regards,

np, thanks for checking. Applied.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Backup docs

2012-06-16 Thread Dimitri Fontaine
Magnus Hagander mag...@hagander.net writes:
 This is copied from the old documentation. It used to say It is not
 necessary to be concerned about the amount of time elapsed between
 pg_start_backup and the start of the actual backup, nor between the
 end of the backup and pg_stop_backup.

 And the whole idea was to simplify the text at the beginning ;)

Oh I see, not your patch to fix then. I just quick read the diff, as you
can see.

 This is copied exactly from what it is today. I'm sure it can be
 approved, but it's not the goal of this patch. Let's not let
 perfection get in the way of improvement...

Same.

 It does, it's under standalone hot backups. The second to last part
 of the patch.

Perfect then.

Sorry for the noise, regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Backup docs

2012-06-15 Thread Magnus Hagander
On Thu, Jun 14, 2012 at 10:37 PM, Robert Haas robertmh...@gmail.com wrote:
 On Wed, Jun 13, 2012 at 3:20 PM, Dimitri Fontaine
 dimi...@2ndquadrant.fr wrote:
 Please let's apply that documentation patch to 9.2 too.

 Agreed.

Here's a patch that does the first two things. Does not attempt a
tl;tr section yet. Also adds a subheader for the notes about
compressing archive logs that seems to have been missing for a long
time - that's definitely valid for things that aren't standalone
backups, and is arguably a lot more *useful* in cases that aren't
standalone backups (since standalone backups won't have very much
log).

No removed text, just moved around and added some.

Unless there are objections to this one specifically, I'll go ahead
and commit it soon.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


backup_docs.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Backup docs

2012-06-15 Thread Dimitri Fontaine
Magnus Hagander mag...@hagander.net writes:
 -The procedure for making a base backup is relatively simple:
 +The easiest way to perform a base backup is to use the
 +xref linkend=app-pgbasebackup tool. It can create
 +a base backup either as regular files or as a tar archive. If more
 +flexibility than xref linkend=app-pgbasebackup can provide is
 +required, you can also make a base backup using the low level API
 +(see xref linkend=backup-lowlevel-base-backup).
 +   /para

Good start.

 +   para
 +It is not necessary to be concerned about the amount of time it takes
 +to make a base backup. However, if you normally run the

Why not?

 +file, and can ordinarily be ignored.) Once you have safely archived
 +the file system backup and the WAL segment files used during the
 +backup (as specified in the backup history file), all archived WAL
 +segments with names numerically less are no longer needed to recover
 +the file system backup and can be deleted. However, you should
 +consider keeping several backup sets to be absolutely certain that
 +you can recover your data.
 +   /para

You're frighting off users when not detailing, I think. How to be
certain I can recover my data, is there a way that I can't when a backup
has been successfully made? How can I check?

Also I don't see mention of basebackup+wal files all in one with the -x
option, which I though would have to be addressed here?

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Backup docs

2012-06-15 Thread Magnus Hagander
On Sat, Jun 16, 2012 at 4:39 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
 Magnus Hagander mag...@hagander.net writes:
 -    The procedure for making a base backup is relatively simple:
 +    The easiest way to perform a base backup is to use the
 +    xref linkend=app-pgbasebackup tool. It can create
 +    a base backup either as regular files or as a tar archive. If more
 +    flexibility than xref linkend=app-pgbasebackup can provide is
 +    required, you can also make a base backup using the low level API
 +    (see xref linkend=backup-lowlevel-base-backup).
 +   /para

 Good start.

 +   para
 +    It is not necessary to be concerned about the amount of time it takes
 +    to make a base backup. However, if you normally run the

 Why not?

This is copied from the old documentation. It used to say It is not
necessary to be concerned about the amount of time elapsed between
pg_start_backup and the start of the actual backup, nor between the
end of the backup and pg_stop_backup.

And the whole idea was to simplify the text at the beginning ;)


 +    file, and can ordinarily be ignored.) Once you have safely archived
 +    the file system backup and the WAL segment files used during the
 +    backup (as specified in the backup history file), all archived WAL
 +    segments with names numerically less are no longer needed to recover
 +    the file system backup and can be deleted. However, you should
 +    consider keeping several backup sets to be absolutely certain that
 +    you can recover your data.
 +   /para

 You're frighting off users when not detailing, I think. How to be

This is copied exactly from what it is today. I'm sure it can be
approved, but it's not the goal of this patch. Let's not let
perfection get in the way of improvement...

 Also I don't see mention of basebackup+wal files all in one with the -x
 option, which I though would have to be addressed here?

It does, it's under standalone hot backups. The second to last part
of the patch.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Backup docs

2012-06-14 Thread Robert Haas
On Wed, Jun 13, 2012 at 3:20 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
 Please let's apply that documentation patch to 9.2 too.

Agreed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Backup docs

2012-06-13 Thread Dimitri Fontaine
Magnus Hagander mag...@hagander.net writes:
 I would like to see that page changed to list pg_basebackup as the
 default way of doing base backups, and then list the manual way as
 an option if you need more flexibility.

+1

 I'd also like to add pg_basebackup -x under standalone hot backups,
 again as the main option.

+1

 I also wonder if we need a tl;dr; section of that whole page that just
 goes through *what to do*, rather than why we do it? Of course not
 removing the details, just showing the simplest case in, um, a simpler
 way?

+1

Come to think about it, that is the perfect occasion to have the
tutorial open itself up to dealing with admin tasks, right?

Please let's apply that documentation patch to 9.2 too.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Backup docs

2012-06-05 Thread Magnus Hagander
In reference to:
http://www.postgresql.org/docs/devel/static/continuous-archiving.html

I would like to see that page changed to list pg_basebackup as the
default way of doing base backups, and then list the manual way as
an option if you need more flexibility.

The reason being that for the majority of users that's going to be
flexible enough, and it's easier to use. And it doesn't hurt to show
that setting these things up really doesn't have to be that hard.

But since I'm definitely slightly biased on this, I'm not going to go
changing anything, or even write up suggested changing, until I can
get some agreement that making this change is good in the first place
;) Thus, please...

I'd also like to add pg_basebackup -x under standalone hot backups,
again as the main option.


I also wonder if we need a tl;dr; section of that whole page that just
goes through *what to do*, rather than why we do it? Of course not
removing the details, just showing the simplest case in, um, a simpler
way?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Backup docs

2012-06-05 Thread Simon Riggs
On 5 June 2012 14:43, Magnus Hagander mag...@hagander.net wrote:
 In reference to:
 http://www.postgresql.org/docs/devel/static/continuous-archiving.html

 I would like to see that page changed to list pg_basebackup as the
 default way of doing base backups, and then list the manual way as
 an option if you need more flexibility.

Agreed, but prefer phrasing old approach as lower level API or similar.


 The reason being that for the majority of users that's going to be
 flexible enough, and it's easier to use. And it doesn't hurt to show
 that setting these things up really doesn't have to be that hard.

 But since I'm definitely slightly biased on this, I'm not going to go
 changing anything, or even write up suggested changing, until I can
 get some agreement that making this change is good in the first place
 ;) Thus, please...

 I'd also like to add pg_basebackup -x under standalone hot backups,
 again as the main option.


 I also wonder if we need a tl;dr; section of that whole page that just
 goes through *what to do*, rather than why we do it? Of course not
 removing the details, just showing the simplest case in, um, a simpler
 way?

 --
  Magnus Hagander
  Me: http://www.hagander.net/
  Work: http://www.redpill-linpro.com/

 --
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers



-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training  Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Backup docs

2012-06-05 Thread Kevin Grittner
Magnus Hagander mag...@hagander.net wrote:
 In reference to:

http://www.postgresql.org/docs/devel/static/continuous-archiving.html
 
 I would like to see that page changed to list pg_basebackup as the
 default way of doing base backups, and then list the manual
 way as an option if you need more flexibility.
 
That sounds reasonable to me, as long as we don't lose information
on the alternatives.  I agree that we should *emphasize* the easiest
steps to set up and run.  The lower-level alternatives could even be
moved to a separate tuning section.  (Speaking of which, if we
have such a section I think it would make sense to describe the
rsync techniques which minimize network traffic in the docs.)
 
Basically, a simple, straightforward description of the easy way to
get going is desperately needed, with alternatives separated out a
bit, with some hint as to when it might be worth going to the extra
trouble..
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers