Skip site navigation (1) Skip section navigation (2)

Re: logical changeset generation v4

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org,Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: logical changeset generation v4
Date: 2013-01-15 15:49:22
Message-ID: 20130115154922.GJ5115@awork2.anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackers
On 2013-01-15 10:28:28 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2013-01-15 15:49:52
Subject: Re: ALTER command reworks
Previous:From: Kohei KaiGaiDate: 2013-01-15 15:40:29
Subject: Re: ALTER command reworks

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group