On 2013-01-15 10:28:28 -0500, Tom Lane wrote:
> Andres Freund <and...@2ndquadrant.com> writes:
> > On 2013-01-15 09:56:41 -0300, Alvaro Herrera wrote:
> >> Oh, hm. Maybe the contrib module's make installcheck, then?
>
> > Thats what I do right now, but I really would prefer to have it checked
> > during normal make checks, installchecks aren't run all that commonly :(
>
> Sure they are, in every buildfarm cycle. I don't see the problem.
>
> (In the case of contrib, make installcheck is a whole lot faster than
> make check, as well as being older. So I don't really see why you
> think it's less used.)
Oh. Because I was being dumb ;). And I admittedly never ran a buildfarm
animal so far.
But the other part of the problem is hiding in the unfortunately removed
part of the problem description - the tests require the non-default
options wal_level=logical and max_logical_slots=3+.
Is there a problem of making those the default in the buildfarm created
config?
I guess there would need to be an alternative output file for wal_level
< logical? Afaics there is no way to make a test conditional?
I shortly thought something like
DO $$
BEGIN
IF current_setting('wal_level') != 'df' THEN
RAISE FATAL 'wal_level needs to be logical';
END IF;
END
$$;
could be used to avoid creating a huge second output file, but we can't
raise FATAL errors from plpgsql.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
