| 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: | Whole Thread | Raw Message | 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 |