Thread: 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 thatplaintext backup format is suitable for a very limited range of use cases, and that in real world people are usuallybetter off with a custom format backup. This is what we want PostgreSQL users to be aware of and provide some hands-onexamples 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. Thankyou. Ivan
Attachment
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.patch > > The patch extends backup.sgml and adds practical information on custom format backups approach. Basically, we believe thatplaintext backup format is suitable for a very limited range of use cases, and that in real world people are usuallybetter off with a custom format backup. This is what we want PostgreSQL users to be aware of and provide some hands-onexamples 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
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
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
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
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 featuresare being deprecated when it isn't the case. We also spent some more time polishing other details, like making adjustmentsto the tone of the text so that it sounds like a manual, not a blog post, more importantly, making it clear thatsuperuser privileges are not always required to perform a successful backup in practice as long as the role used to makethe backup has sufficient read privileges on all of the objects a user is interested in. We also mention and show examplesof usage for pigz alongside with gzip, and probably something else too :P Please, see the diff file attached to thismessage for complete and detailed log of the changes.