On Fri, Feb 24, 2012 at 3:31 PM, Daniel Farina <dan...@heroku.com> wrote: > Having been in this position once before in a different but similar > situation, there's one big caveat: initdb is *really* slow, so it is > really painful for people who write Postgres-linked code that is > compiled separately, whereby the initdb binary is stable. The > frustration is not unlike when I have to run ./configure, except I had > to do it all the time, every time. > > A ccache-like solution has worked well for at least one person I know, > and wasn't hard to implement(?) for personal use.
Being the person in question: I don't have the full context so I'm not sure how useful this will be, but here's hoping it's not just line noise. I'm probably not at liberty to share the original code, but it was a fairly trivial shell script that did more or less the following: 1. Capture all arguments (to pass to initdb itself) except the path, and figure out the path to the cluster (via looking for -D/--pgdata/$PGDATA) 2. Create a hash of the concatenation of the arguments (again, sans cluster path) 3. Create a "template" path based on a local cache directory and the argument hash 4. a) If the directory with this path did not exist, run initdb with -D set to this and the rest of the arguments as captured; then copy to *actual* path b) If it does exist, that's because you've run initdb with these arguments before: just copy that to the cluster path you captured in step (1) instead of starting fresh This was not terribly robust (e.g., I remember that Dan had pointed out several shortcomings), but none of these were practical issues for me, and I never had a problem. There is some more work around capturing the cluster path in the initdb output and mangling it back from the template version into the original (so the output of the cached initdb looks like output of a real initdb), but that's not a big deal. The approach could probably be made solid enough for general-purpose use. -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers