Re: Errors when trying to use git.postgresql
От | Daniel Farina |
---|---|
Тема | Re: Errors when trying to use git.postgresql |
Дата | |
Msg-id | 7b97c5a40901140952m28d53a01xc8d2daec8cd2aab3@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Errors when trying to use git.postgresql ("Dave Page" <dpage@pgadmin.org>) |
Ответы |
Re: Errors when trying to use git.postgresql
|
Список | pgsql-www |
On Wed, Jan 14, 2009 at 12:58 AM, Dave Page <dpage@pgadmin.org> wrote: > This happens on the local machine presumably? I used to suffer that > problem and resolved it with 'ulimit -n 1024' in my bash profile. This is because the number of packs in the git.postgresql.org repo is enormous, which also slows down clones and many other git operations. Try running "git gc --aggressive" to fix this on your local copy (this will take a while -- probably hours -- unless you've done it before). On the other hand, I've recorded a size difference in the pack going from > 300 MB to ~100MB. Using a fresh clone from git.postgresql.org I had to actually raise ulimit -n above 1024 to perform this operation, or else I hit my open file limit. You should also notice a marked improvement in the performance of certain operations. From time to time I recommend running a regular 'git gc' to consolidate packs. Newish versions of git feature automatically triggered gc to do these things, precisely to avoid the kinds of problems you describe. The setting "gc.autopacklimit" to determines how many pack files are allowed. I don't know what the default is. If you are especially impatient, you can clone the repository mentioned previously (you will inherit the repacking I've already done) and port your patches over using "git format-patch" and "git am" or even just adding your old repository as a remote and fetching the branches. You can then set the "origin" remote to git.postgresql.org to continue getting updates from there. fdr
В списке pgsql-www по дате отправления: