From: | Daniel Farina <daniel(at)heroku(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Sandro Santilli <strk(at)keybit(dot)net>, Christoph Berg <cb(at)df7cb(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Runtime SHAREDIR for testing CREATE EXTENSION |
Date: | 2012-02-24 23:31:36 |
Message-ID: | CAAZKuFbqetmyhE0mDYffaUQ7Cnh1iTjcHF6Q8hK1xkD2e0JYng@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 24, 2012 at 10:21 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On fre, 2012-02-24 at 17:26 +0100, Sandro Santilli wrote:
>> We don't initdb with PostGIS regression testing framework
>> but I've considered doing it for this specific case and it stroke me
>> that even then we couldn't control SHAREDIR.
>
> I would always create a new instance using initdb for test runs. It's
> easy and avoids all these problems.
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.
But by hook or crook, a fresh database is the "right" thing for sure.
--
fdr
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2012-02-24 23:43:40 | Re: Command Triggers, patch v11 |
Previous Message | Thom Brown | 2012-02-24 23:01:54 | Re: Command Triggers, patch v11 |