Re: Some more bugs tables need to be exportet (Was: Any chance to pg_dump UDD partially)
On 12/11/12 at 15:29 +0100, Andreas Tille wrote:
> On Sun, Nov 11, 2012 at 09:55:33AM +0100, Lucas Nussbaum wrote:
> > $ grep -lr udd-bugs.sql /srv/udd.debian.org/udd
> > /srv/udd.debian.org/udd/scripts/clone_udd_bugs_fetch.sh
> > /srv/udd.debian.org/udd/scripts/dump-db.sh
> > /srv/udd.debian.org/udd/scripts/clone_udd_bugs_inject.sh
>
> Uhhh, very easy - I coudl have sworn I have done this before my posting.
> :-(
>
> So I applied the following patch:
>
> diff --git a/scripts/dump-db.sh b/scripts/dump-db.sh
> index 6867247..5308bf9 100755
> --- a/scripts/dump-db.sh
> +++ b/scripts/dump-db.sh
> @@ -7,5 +7,9 @@ pg_dump --no-owner -p 5452 -n history udd | gzip > udd-history.sql.gz.new
> mv udd-history.sql.gz.new udd-history.sql.gz
> pg_dump --no-owner -p 5452 -T ldap -T really_active_dds -T pts udd | gzip > udd.sql.gz.new
> mv udd.sql.gz.new udd.sql.gz
> -pg_dump --no-owner -p 5452 -t bugs -t bugs_blockedby -t bugs_blocks -t bugs_fixed_in -t bugs_found_in -t bugs_merged_with -t bugs_packages -t bugs_tags -t bugs_usertags udd |gzip > udd-bugs.sql.gz.new
> +pg_dump --no-owner -p 5452 \
> + -t bugs -t bugs_blockedby -t bugs_blocks -t bugs_fixed_in -t bugs_found_in -t bugs_merged_with -t bugs_packages -t bugs_tags -t bugs_usertags \
> + -t archived_bugs -t archived_bugs_packages -t archived_bugs_merged_with -t archived_bugs_found_in -t archived_bugs_fixed_in -t archived_bugs_tags -t archived_bugs_blocks -t archived_bugs_blockedby \
> + udd |gzip > udd-bugs.sql.gz.new
> mv udd-bugs.sql.gz.new udd-bugs.sql.gz
> +
>
>
> However, before I might move it effectively into action I would like to
> stress that the change turns the udd-bugs.sql.gz from previousely less
> than 10MB to 65MB (in other words more than 10% of a full dump). Do you
> think this is acceptable?
Yes
> BTW, I also tried xz compression which turns original 65MB into 35MB. I
> don't know about what you might care much - processing time at
> udd.debian.org or bandwith - but may be that might be an option
> (probably even more for udd.sql because more people might download
> this.) In case it helps deciding I might add the comparison of time
> needed to compress using gz and xz.
I don't really care about any of those, since the compression is only
run once a day anyway. It probably makes sense to continue to use .gz as
switching to .xz would require notifying users of the .gz file.
Lucas
Reply to: