backup.sgml patch that adds information on custom format backups
Hello,
I'd like to submit the following patch that extends backup.sgml with a bit of practical but important information.
Project: postgresql
Patch filename: backup.sgml-cmd-v001.patch
The patch extends backup.sgml and adds practical information on custom format backups approach. Basically, we believe that plaintext backup format is suitable for a very limited range of use cases, and that in real world people are usually better off with a custom format backup. This is what we want PostgreSQL users to be aware of and provide some hands-on examples of how to do backups using this approach.
It is meant for application, and is against master branch.
The patch does pass 'make check' and 'make html' successfully.
PS: this is my first submission ever. So, if I'm missing something or not doing it as expected, please, do let me know. Thank you.
Ivan
Attachments:
backup.sgml-cmd-v001.patchapplication/octet-stream; name=backup.sgml-cmd-v001.patchDownload+82-0
On Fri, Feb 8, 2013 at 1:56 PM, Ivan Lezhnjov IV <iliv@commandprompt.com> wrote:
Hello,
I'd like to submit the following patch that extends backup.sgml with a bit of practical but important information.
Project: postgresql
Patch filename: backup.sgml-cmd-v001.patchThe patch extends backup.sgml and adds practical information on custom format backups approach. Basically, we believe that plaintext backup format is suitable for a very limited range of use cases, and that in real world people are usually better off with a custom format backup. This is what we want PostgreSQL users to be aware of and provide some hands-on examples of how to do backups using this approach.
It is meant for application, and is against master branch.
The patch does pass 'make check' and 'make html' successfully.
PS: this is my first submission ever. So, if I'm missing something or not doing it as expected, please, do let me know. Thank you.
Generally it's a good idea to discuss whatever you'd like to change
before you actually write the patch, so as to get consensus on it.
I'm not sure what others think, but the proposed wording seems a bit
hard on plain text dumps to me. For many people, the advantage of
having a file in a format you can read may outweigh the disadvantages
of being unable to do a selective restore. Not that custom-format
dumps aren't great; they certainly are. But it isn't a bug that we
support more than one format.
--
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
Robert Haas <robertmhaas@gmail.com> wrote:
I'm not sure what others think, but the proposed wording seems a
bit hard on plain text dumps to me.
Agreed. I don't know how many times I've piped the output of
pg_dump to the input of psql. Certainly that was very common
before pg_upgrade was available. And for development purposes a
text script file is often exactly what is needed -- to store it in
custom format first would just be an extra step which would waste
time. Since I got my head around PITR dumps, I've rarely had a
reason to use the pg_dump custom format, myself.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
I'm not sure what others think, but the proposed wording seems a bit
hard on plain text dumps to me.
I wasn't terribly thrilled with labeling pg_dumpall "deprecated",
either. It might be imperfect for some use cases, but that adjective
suggests that we're trying to get rid of it, which surely isn't the
case.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello everyone!
I'd like to thank you for quick replies and for the thoughtful feedback.
I'm working on improving the current wording and I'm going to follow up shortly with an updated version.
Please, stay tuned.
Ivan
On Feb 11, 2013, at 12:15 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
I'm not sure what others think, but the proposed wording seems a bit
hard on plain text dumps to me.I wasn't terribly thrilled with labeling pg_dumpall "deprecated",
either. It might be imperfect for some use cases, but that adjective
suggests that we're trying to get rid of it, which surely isn't the
case.regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alright gentlemen here we go, take two.
backup.sgml-cmd-v002.patch addresses your feedback and offers a better worded statements that avoid implying that some features are being deprecated when it isn't the case. We also spent some more time polishing other details, like making adjustments to the tone of the text so that it sounds like a manual, not a blog post, more importantly, making it clear that superuser privileges are not always required to perform a successful backup in practice as long as the role used to make the backup has sufficient read privileges on all of the objects a user is interested in. We also mention and show examples of usage for pigz alongside with gzip, and probably something else too :P Please, see the diff file attached to this message for complete and detailed log of the changes.