On Fri, Feb 24, 2012 at 3:31 PM, Daniel Farina <daniel@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.
